Я уже рассказывал, что в свободное время занимаюсь своим микрофреймворком и хочу поделиться некоторыми мыслями по этому поводу. Речь пойдёт о представлениях (view) в концепции MVC, точнее о том, что они на самом деле представляют.
Это скорее мысли вслух, а не готовые решения. Я даже буду рассуждать больше абстрактно, чтобы можно было примерить идеи под любой php-фреймворк.
Суть паттерна отражает его название — использовать два несовместимых между собой класса через некий общий интерфейс. То есть создаётся класс-оболочка, которая скрыто выполняет нужный класс. По своему поведению, Адаптер очень похож на Фасад. Правда под Фасадом больше понимается именно скрытие реализации за каким-то общим методом, а Адаптер предполагает именно «приведение» классов к одному типу.
Исходный код Адаптера вы можете посмотреть на гитхабе.
Кратко опишу что в нём происходит. Есть два совершенно разных класса. Но при этом, мы хотим привести их к некоему одному типу/поведению в рамках своего проекта. В данном случае это интерфейс AdapterInterface. Дальше делаются классы, реализующие этот интерфейс: AdapterA и AdapterB.
Метод commonMethod()является обязательным, и в нём мы уже подключаем существующие методы классов ClassA и ClassB. Такой подход позволяет использовать в приложении совершенно разные классы с нужным интерфейсом.
Запустил telegram-бот MaxSiteOrg_bot для своего (этого) сайта. Бот в общем-то больше призван показать возможности ботов как таковых, а также возможную интеграцию с сайтом. Например доступен вывод последних записей, рубрик и меток.
Ботами я заинтересовался недавно, поэтому текущая версия базовая. В планах реализовать ещё несколько возможностей для организации диалогов. Это нестандартная возможность для API Telegram'а, но, как мне кажется интересная и может быть востребована.
Так же я решил принимать заказы на создание ботов для сайтов. Главное условие чтобы ваш сайт работал по https и на PHP 7.1 и выше.
PHP Standards Recommendations — это набор рекомендаций для разработчиков на PHP. Отношение к PSR разное: от полного неприятия, то фанатичной преданности. Сам по себе PSR появился как копирование Java Community Process (ага, опять Java!). Основное назначение PSR в том, чтобы предоставить PHP-разработчикам некие общие концепции, которые уже были проверены и отработаны.
На сегодняшний день существует 20 рекомендаций PSR. Часть из них находится в активном статусе, другие в виде черновиков. Есть «заброшенные» и отмененные рекомендации. В общем «движуха» достаточно активная. Попробуем во всём этом разобраться.
За это лето я успел сделать несколько важных изменений в MF. Вообще MF отличается от других шаблонов тем, что содержит множество модулей, блоков, компонентов и одна из проблем: как этим всем управлять. Например сейчас 48 модулей для главной — необходимо было придумать механизм, который позволит клиентам визуально подбирать блоки без правки исходных файлов.
Аналогичная проблема возникла с компонентами шапки: на основе существующих компонентов можно составить разные варианты блоков, даже между теми, которые для этого не предназначены. Всё это привело меня к мысли, что нужно плотно заняться удобством управления. Тем более, что я и дальше планирую наращивать количество блоков шаблона.
Работа с базой данных всегда была сильной стороной CodeIgniter. В 4-й версии сохранился практически тот же самый подход, что и в прошлых версиях, хотя есть отличия. В первую очередь стоит отметить, что SQL Query Builder (Active Records в первой и второй версиях) теперь вынесен отдельным классом. Если раньше SQL-запрос строился прямо в объекте базы ($db), то сейчас это нужно делать отдельно.
Основной объект базы теперь содержит не так много методов, наиболее используемый из которых query().
Но самое главное это то, что CodeIgniter 4 поддерживает Named Bindings, что очень сильно его приближает к стандартной работе с PDO.
Где-то с нового года я занимаюсь разработкой своего PHP-фреймворка. Без каких-либо обязательств, просто для себя. Во что это выльется я не знаю, да и цели сделать его публичным пока не стоит. Изначальный посыл был несколько лет назад: я серьёзно подумывал отказаться от CodeIgniter в качестве основы MaxSite CMS. Продумывал новую структуру и всё что с этим связано. Постепенно я понял, что затея тупиковая, поэтому решил сосредоточиться на более простой вещи — микрофреймворке, который даст основу уже полноценной разработке.
За это время фреймворк я переписывал с нуля раз 100. Вначале делал как мне казалось верно, после пытался применить на практике, натыкался на проблему, пытался её решить, понимал, что нужно сделать проще поэтому менял основу и дальше новая итерация цикла.
Возможно сказывается ещё тот факт, что за много лет работы со своей системой у меня накопился не просто большой опыт решения сложных задач, но и понимание тех самых «тупиков», которые приходится обходить нестандартными способами. Так что хочется сразу сделать правильно. Поделюсь некоторыми мыслями на этот счёт.
| Результаты |
Идет загрузка…
