Сниппет, плагин, модуль... аддон? Чего мне не хватает в ModX.

1. Вместо предисловия.

Сразу оговорюсь — речь пойдет исключительно о ветке Evo. С Revo пока вплотную не сталкивался, возможности ее не изучал.

И еще одна оговорка. Эта заметка пишется только для размышлений. Ни одной строки кода еще не написано.

2. Причины написания.

В процессе работы над одним из сайтов заказчика столкнулся с невозможностью написать более-менее абстрактный код. Постоянные договоренности с самим собой об использовании переменных в качестве переключателей режима вывода начали раздражать почти сразу. TV в документах появлялись в устрашающих количествах, причем назначение их было тем же: просто сигнализировать о настроении верстальщика. Когда одна из функций в зависимости от 2х таких переключателей стала возвращать 3(!) различных типа данных (массив, строка или false) я пришел к пониманию того, что я где-то ошибся.

Вместе с тем, я параллельно обдумывал несколько возможностей, которых не хватает в ModX. Пока эти мысли еще свежи, попытаюсь их оформить.

3. Постановка задачи
Предположим, нам нужно создать веб-приложение. Предположим также, что во всем мире победил здравый смысл и все джумлы и друпалы загнулись ModX для нас не имеет альтернативы, скажем есть уже действующий сайт, который переделывать ни к чему. Какие у нас есть варианты действий?

Первое, что приходит в голову в таких случаях — интеграция готового решения. Скажем, прикрутить к ModX LiveStreet. Работает, если уделить немного времени. Но удовлетворения эта работа не приносит, особенно, если что-то вдруг начинает барахлить. Тем не менее, примерно в 90% случаев этот метод более-менее удовлетворительно используется. Назовем это подходом опытных веб-мастеров.

Второе, чуть более затратное по времени. Снова использовать готовый код, но собрать требуемый функционал из лоскутов, допиливая и сваливая в кучу отдельные скрипты из разных источников. Это подход фанатиков и начинающих. Ни о нормальной работе, ни об удовлетворении от результата или процесса речь не идет.

Третье — открыть свой велосипедный цех и, поглядывая в 2-6-10 готовых решений аналогичного функционала, сделать все под себя самостоятельно или с напарниками. Это подход хорошо оплачиваемых наемников или сторонников свободного ПО.

Не переходя на личности, выбираем третий вариант. Пишем нужное нам веб-приложение сами.

Бац! Нам не хватает таблиц в БД ModX.
Бац! API ModX не умеет ловить мышей.
Создали таблицы. Написали методы.
Бабах! Структура данных не подходит под изменившиеся условия.

Ну и так далее.

И вот тут возникает мысль. А что если создать полностью независимое ядро веб-приложения, которое само будет следить за своими таблицами и мышеловками (раз уж о них зашла речь), иметь свои собственные расширения (они же плагины) и подключаться в ModX в виде сниппета/плагина/модуля для интеграции в уже существующие сервисы сайта?

Да, ModX в этой ситуации будет выступать больше шаблонизатором, чем движком. Но, быть может шаблонизатор с такими возможностями — это и есть вершина of Evolution, простите за каламбур.

Вот тут я добрался до сути своей заметки. Но прежде надо сделать одно небольшое, но важное отступление.

4.MVC и другие страшные слова.
В этом месте просятся сразу несколько эпиграфов. Остановлюсь на замечании посетителя какого-то давно посещенного форума. Не дословно, но он заявил следующее. Мода в программировании дает зубодробительные названия простым вещам. Потратив месяц на понимание сути MVC он вдруг понял, что и так всю жизнь писал код, подходящий под эту идею, но ему не приходило в голову обзывать свой подход какими-то сложными словами.

Для тех, кто не очень в курсе, объясню быстро, о чем идет речь. Модель MVC — это просто способ организации кода. При использовании такого способа размер кода увеличивается, но зато код становится очень универсальным, не зависящим от конкретных условий использования. Данные, которые приходят от пользователя проверяются в одном месте. Данные из таблиц или файлов извлекаются в другом. В третьем месте формируется HTML код, который уйдет к пользователю. Но это еще не MVC. А вот если мы начнем между этими тремя частями передавать данные в каком-то внутреннем формате (xml, json, сериализованный массив), причем маршрут этих данных будет построен от внешнего к внутреннему и обратно — это будет уже почти MVC. Почти — потому что у веб-приложения должна быть только одна точка входа (1 скрипт, который управляет маршрутами данных, index.php например). И еще потому, что никто в целом мире не может вразумительно сказать, что вот это — MVC, а вот это — профанация. Много ругани и умных терминов в комментариях к статьям по MVC, напоминает подчас какой-то птичий язык, а суть все время ускользает.

Поэтому скажу вот что. Главный критерий удобства MVC — возможность изменять код в одном месте, не затрагивая любые другие места. Если это удалось, можно смело говорить об использовании MVC в собственой трактовке. А интерфейсы и реестры — вопрос терминологии.

5.Постановка задачи (продолжение)
Что я хочу получить от своего кода? Вот как мне видится все в теории.

ModX я оставляю функцию точки входа в веб-приложение. Здесь все остается, как и было. Создаем в дереве документов по одному документу для каждого типа страниц. Назначаем им шаблоны. Какие-то страницы будут работать прямо из ModX. Страницы нашего приложения будут содержать вызов сниппета. Для определенности назову его [[mxAddon]].

Сам сниппет будет содержать include для файла, который назовем kernel.php, и который будет обеспечивать обмен данными между ModX и нашим аддоном. Данные из аддона будут приходить в json (почему — см. ниже), сниппет будет вызывать parseChunk и раскладывать кусочки данных по чанкам.

Пока ничего необычного.

Если нам необходима функциональность плагина или модуля ModX — то в теле плагина/модуля будет (сюрприз!) include 'kernel.php' и обработка чанков.

Такой подход позволит нам имея 1 аддон сразу создавать плагины, сниппеты, модули с любыми названиями и просто страницы или ajax ответы (вот почему json). Внешний вид всего этого мы отдаем на откуп ModX или же вообще яваскрипту на стороне клиента.

Тоже никакого прорыва.

Взглянем на наш kernel.php. Что он должен уметь? Во-первых, сразу загружать конфиг нашего аддона. Наше приложение должно осознать себя в этом мире. Во-вторых, ядро должно обработать запрос и сообразить, что от аддона хотят получить. В-третьих, сформировать команду на получение данных от внутренних частей аддона. И в четвертых, получив ответ от подчиненных передать его на выход. Это пока все.

Теперь пройдем дальше. Ядро на третьем этапе посылает внутренний запрос — но куда? Туда, где нет никакого HTML кода, где есть только набор бездушных переключателей. В зависимости от положения этих переключателей будет сформирован json ответ ядру. Но кто меняет положение переключателей? В терминах MVC это и есть контроллер, он же мистер C. И вот тут мы можем оторваться по-полной.

Весь функционал нашего аддона мы можем разложить на элементарные действия. Чтобы не путаться в терминах с ModX, назову их не плагинами, а например драйверами (а чё, кернел ведь есть). А чтобы было еще веселее, можно назвать контроллерами (не теми, что в MVC, а теми, что прерывания от ОС получают) интерфейсы обращения к файлам или БД. Но путаница в терминах нам не нужна, поэтому пока оставим интерфейсам их название.

6. К чему все это?

Применений этому механизму можно придумать много. Вопрос только в том, даст ли эта стратегия хоть какой-то выигрыш в чем-нибудь.

Пример. Хотим мы прикрутить к ModX форум. Устанавливаем готовый движок форума в отдельную директорию. В ModX создаем документ Forum. Где-то в шаблоне (скорее всего MinimalTemplate) пишем [!mxAddon? &mode=`forum`!]. В папке с kernel.php создаем директорию drivers/forum/, в которой будет лежать driver.php и управлять как минимум авторизацией пользователей, а в качестве интерфейса будет вызываться или подключаться index форума.

Еще пример. Написали пару велосипедов с посторонними таблицами. Как в них проводить поиск? drivers/sphinx и вперед.

7. Чего в супе не хватает?

Самое тяжелое в проектировании этого механизма — сразу выбрать правильный формат передачи команд и ответов между ядром и драйверами. Json — это хорошо и правильно, но «есть нюанс». В примере выше движок форума вряд ли захочет отдавать его контент в json формате. А хакать ядро — не дает никаких преимуществ. Если кого-то заинтересует эта тема, можно порассуждать вместе.

8. Заключение.

Эта заметка ни на что не претендует и ни к чему не призывает. Это просто игра ума.

Тем не менее, если будет интерес, я планирую написать еще как минимум одну заметку уже с кусками кода. В бурном потоке критики иногда можно поймать неплохую рыбу здравого смысла.