XML, XSLT и ядро

Я некоторое время работал с несколькими разными движками сайтов. Но рано или поздно возникала необходимость что-то доделать/переделать. Поэтому приходилось копаться в структуре, пытаясь понять чужой некомментированый код. Это было сложно. И я пришёл к выводу, что лучше написать свой собственный фреймворк. Кроме того, я решил, что сам фреймворк должен быть максимально компактным и простым, а большую часть кода, который может потребовать изменений лучше перенести подальше от ядра.

Испробовав несколько вариантов, я решил взяться за связку 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 будет не слишком простым для усваивания.