Я некоторое время работал с несколькими разными движками сайтов. Но рано или поздно возникала необходимость что-то доделать/переделать. Поэтому приходилось копаться в структуре, пытаясь понять чужой некомментированый код. Это было сложно. И я пришёл к выводу, что лучше написать свой собственный фреймворк. Кроме того, я решил, что сам фреймворк должен быть максимально компактным и простым, а большую часть кода, который может потребовать изменений лучше перенести подальше от ядра.
Испробовав несколько вариантов, я решил взяться за связку
XML+
XSLT. То есть, все данные сайта должны храниться в
XML-файлах, а все шаблоны для страниц - представлять из себя
XSL-документы. Ядро движка, собственно, занимается связыванием этих двух элементов.
Возможности
XSLT позволяют перенести львиную долю механики страниц в сами
XSL-шаблоны. То есть, чтобы отстортировать ту таблицу или вывести данные из другого объекта, мне не нужно менять код - только модифицировать шаблоны.
Написать движок, который занимается скрещиванием
XSL-шаблонов и
XML-данных - довольно просто. Но такой движок никому не нужен, если мы не обеспечим пользователю возможность управлять содержимым сайта. То есть, нужна
CMS. Это уже сложнее.
Однако, у backend-систем есть одно преимущество - не нужно морочить себе голову обеспечением корректной индексации страниц поисковыми системами. В конце концов, они закрыты от посторонних. Поэтому я принял решение использовать в
CMS элементы
Ajax как основное средство управления.
Поэтому в ядро движка нужно добавить интерфейс для работы с запросами скриптов
Ajax. По сути, со стороны сервера, это тот же
XSL-трансформатор, который применяется при генерировании страниц. Так что его можно совместить с тем, что уже написано, всего лишь дописав несколько рутинных процедур для обработки POST и GET запросов. Остаётся только написать Javascript-код, отвечающий за обмен данными с интерфейсом на сервере.
Таким образом, весь алгоритм работы ядра движка сводится к получению запроса от клиента, выбора нужных
XML- и
XSL-документов, трансформации и отправке клиенту результата. Конечно, нужно предусмотреть выполнение ряда действий касательно данных в процессе обработки запроса, но этот функционал лучше вынести из ядра в отдельный набор функций или классов. Кроме этого нужно будет обеспечить инфраструктуру рутинных процедур (например, разборка GET-запроса или сохранение файлов из POST-сообщений).
Конечно же, такая архитектура не совсем подходит для сайтов с большими базами данных. В таких случаях лучше воспользоваться классическими
SQL-решениями (хотя, что нам мешает интегрировать
SQL-интерфейс в ядро?). Однако для большинства сайтов, как оказалось, будет достаточно вышеописанной схемы.
Преимуществом архитектуры является её простота - эффект автомата Калашникова :). Обучить постороннего человека работать с этой архитектурой - довольно просто, однако от него требуется знание
XSLT. И по собственному опыту я знаю, что после длительной работы с классическими языками программирования,
XSL будет не слишком простым для усваивания.
Ярлыки: dev, xml, xslt, веб-архитектура
