После нескольких проектов, с раздутыми структурами и неуловимой тормозящей структурой инклудов, я попробывал сделать что то более удобное и оптимальное.
Всё началось с того, что я пытался избавиться от инклудов. Да, да :)
Параноидальная оптимизация каждой строки и тесты привели меня к выводу, что для достижения максимальной оптимизации,
необходимо что бы каждая страница использовала только необходимые ей структурные блоки. И все эти структурные блоки должны быть частью страницы.
Как раз в это время я активно изучал реализацию ООП в php, и
решил в своем парсере называть структурные блоки — контейнерами, которые являются методами классов.
Теперь весь проект для меня представлялся в четко структурированных блоках, каждый из которых мог использоваться где угодно на сайте. Для лучшего восприятия структуры, все блоки используют некорректные теги, для которых у меня в Zend Studio применяется фиолетовый цвет.
Приведу пример структуры для главной страницы сайта:
Почему для меня это удобно:
1. Гибкое управление разработкой
Часто приходится сталкиваться с тем, что необходимо срочно внести некоторые изменения в сайт, но при этом, редактируя самые важные области,
отвечающие за соединение с базой данных или другим критическим частям сайта, Вы совершаете ошибку и сайт встречает новых посетителей унылым дизайном (в лучшем случае) или полным отсутствием содержания.
Видел пока что только 2 варианта решения этой проблемы:
Редактирование копии файла на одной из скрытых страниц сайта или редактирование сайта на локальном сервере и потом уже загрузка уже работающей модели.
Ну и самый ко ординальный, это редактирование по ночам, когда большей части юзеров уже не до вашего сайта.
В моём парсере я указываю какие страницы необходимо пересоздать с помощью регулярного выражения.
Поэтому мы можем проводить испытания на одной странице сайта, или на целом сегменте, а затем моментально обновить все остальные :)
2. Контроль над кодом проекта
php файлы чаще всего хранят прямо в корне сайта, и поддиректориях, и абсолютно не поддерживают порядок.
Некоторые веб-мастера вообще не представляют, какой код у них хранится и начинают писать заново те функции, которые похоронены в глубине сайта.
С помощью этого парсера Вы можете хранить весь код вашего проекта в одном файле (например project.xml).
Однако это не обязательное условие. Для удобства, Вы можете создать ещё какое угодно количество файлов и положить их в директории как Вам будет угодно.
3. Гибкий синтаксис
При изучении новых фреймворков и шаблонизаторов часто впадаешь в ступор от нелогичных, как Вам кажется названий функций.
В парсере Вы можете сами задавать какие душе угодно имена и изменять их действия. Дописать, или удалить ненужные функции.
4. Оптимизация php, css, (x)html кода
Скриптов для сжатия css и (x)html кода довольно много. А вот Zend Optimizer стоит далеко не на каждом хостинге, да и
не все себе могут такой хостинг позволить. Да, и не забываем про include? :)
В парсере Вы можете оптимизировать php,css,(x)html,js код как Вам угодно. Указанная вами функция а-ля include
будет вставлять содержимое файла прямо в страницу.
5. Создаём статичные html сайты
Для создания статичных сайтов больше не надо писать самописные парсеры, мой отлично с этим справляется :)
С чего начинать?
Для начала нам нужно иметь 3 файла:
1 — сам компилятор ( к нему также идет ajax — клиент для удобной работы )
2 — основной файл проекта (например project.xml)
3 — файл валидных страниц (просто список страниц, которые нам необходимо перекомпилировать)
Теперь, нам необходимо определится, какую разметку мы хотим использовать.
Глобавльные правила
Если в вашем проекте активно используется ООП, что избежать конфликтных ситуаций мы зададим используемые классы в разметке.
По умолчанию глобальные правила проекта задаются в конструкции .
Например
!class area
!class unicate
!class moiclass
Мы можем придумать и использовать свою разметку, например
#define moiclass
В любом случае, если парсер не находит глобальных правил, будут анализироваться все конструкции, которые подпадают под регулярное выражения
для валидных классов.
Зачем ещё глобальные правила?
Пример: Вы решили добавить во все страницы каталога /catalog/ всего одну строку <? error_reporting(0); ?>
Конструкцией !method.AddBefore.regexp(^/catalog/).string{{{<? error_reporting(0); ?>}}} (привожу как пример)
Мы добавим перед всеми начинающимися с /catalog/ данную строку.
Разметка основных конструкций
UPD: В Соответствии с основами Аспектно-ориентированного программирования, исправил основные понятия.
JointPoint ( <class::method> по умолчанию ) – определённая точка в выполнении программы: выполнение метода, изменение атрибута класса,
вызов метода, выбрасывание исключения и т.д.
<class.method></class.method> (Aspect) аналог класса может содержать в себе неограниченное количество JoinPoint (<class::method>) или просто строки php / html / css.
#include file — простая замена строки содержимым файла.
UPD: Спасибо за комментарии, не зная о существовании АОП использовал его принципы.
