Идеальный фреймворк (продолжение)

Хороший PHP фреймворк – это не готовый набор функций, а процесс. Вернее, так: фреймворк – это срез, застывшее в определённый момент состояние процесса упорядочивания функций (функций – в широком смысле, включая классы, интерфейсы и прочую дребедень). Всё, что может быть использовано в качестве шаблона для целого сайта, является фреймворком. Фреймворк может быть лучше или хуже. Рассмотрим пример: сайт из двух HTML-страниц.

Можно взять эти страницы за основу и, заменяя в них всё, что написано русскими буквами, создавать таким способом новые двухстраничные сайты. Маленький двухстраничный фреймворк. Что в нём плохо?

Если вы захотите поменять цвет текста с красного на зелёный, вам придётся делать это на каждой странице.
При изменении смысла текста (например, с «Прощай...» на «Давай познакомимся поближе») придётся менять текст ссылок в разделе навигации на каждой странице.

То есть трудно управлять изменениями. Это основной аргумент любителей хороших фреймворков: «Да, ваша система будет нормально работать. До тех пор, пока вам не понадобится добавить ещё одно поле в таблиццу. А когда понадобится, возникнет большой гемор».

В нашем примере больших проблем возникнуть не должно – это, скорее, вопрос инструментов. Можно специальными программами (например, «Far файл менеджер» + sr) менять один фрагмент текста на другой в нескольких файлах сразу. Например, одной командой заменить строки навигации сразу в двух файлах. Или заменить так же "color:red" на "color:green". Но ясно, что это до поры; инструмент имеет предел точности: например, если на одной странице будет два абзаца с разными цветами, возникнет коллизия, и командой замены решить задачу станет нельзя.

Для того и придумали выносить правила CSS в отдельный файл и прикреплять его ко многим HTML-страницами с помощью элемента link. С использованием этой возможности файлов станет три, а управлять видом HTML страниц можно будет, меняя правила CSS в одном файле (отделяем Представление от Данных). Заодно (чтоб два раза не бегать) вынесем «за скобки» (в отдельный файл) и меню:

Не забудем и о файле .htaccess, в который надо будет добавить инструкцию для SSI (Server Side Includes) – распознавания выражений вида #include virtual в файлах .htm на сервере:

Вот это и есть основная часть фреймворк-процесса – вынесение части кода «за скобки», на более высокий уровень абстракции. Неотъемлемой частью этого процесса являются (новые) инструменты; в нашем примере – CSS и SSI (добавленные к «голому» HTML). Следующим инструментом неизбежно будет какая-то более сложная программа, исполняемая на стороне сервера. Чаще всего сейчас это быват PHP. Но раньше инструмента должна всё-таки появиться потребность (иначе новым, более сложным инструментом вы продолжите забивать гвозди).

Эта потребность – ряд проблем меню сайта, описанных нами в статье http://dn.ir2.ru/mvc0.aspx. Одна из наиболее очевидных проблем – синхронизация меню с реальностью: при добавлении новой страницы на сайт надо не забыть добавить в меню новую ссылку. PHP скрипт может решить эту проблему (а заодно и некоторые другие), в результате чего вы просто будете добавлять новую страницу, не заботясь о меню (там ссылка будет появляться автоматически).

Заметим, что само по себе появление серверного скрипта не развивает фреймворк-процесс: мы ничего нового в данном случае не выносим «за скобки», а только делаем более удобным процесс обновления сайта. Можно сказать, начинаем создавать некоторое «пространство CMS». Совершенно определённым вынесением «за скобки» на уровне PHP можно было бы считать следующую ситуацию:

Есть два виртуальных хоста (разных сайта) с документами в папках, например /home/site1/www и /home/site2/www.
Оба сайта используют один и тот же скрипт генерации меню, который, очевидно, должен находится выше уровня, где начинаются различия; например, в файле /home/menu.php. Впрочем, предполагая, что это не последний общий файл, разумнее поместить его в специальную папку /home/framework/menu.php.

Вот здесь и возникает проверка на вшивость самого главного принципа, или паттерна, или шаблона проектирования фреймворка – изоляции кода (ага, а вы думали, главный шаблон для фреймворка – mvc?..). Мы создали для двух разных (более-менее) сайтов общий скрипт генерации меню – menu.php. Будет ли он без проблем работать с третьим, неизвестным сайтом?

И второй, такой же важный вопрос: будет ли вообще вся эта фигня летать? Понятно, что теоретически возможно создать сверх-универсальный скрипт, который сможет генерировать все известные в мире виды меню. Но сколько мегабайт кода (и ресурсов сервера) он займёт?

Вот это, пожалуй, и есть основная Сцилла и Харибда PHP-фреймворка: воспроизводимость (повторное использование) кода vs скорость. Понятно, что тут не всегда есть противоречие. Например, наш маленький скрипт написания чисел прописью http://dn.ir2.ru/Num2rub.php воспроизводим практически в любом контексте, и очень прост и быстр. И абсолютно бесполезен для громадного количества сайтов – из-за узкой направленности. Борьба воспроизводимости со скоростью возникает только в областях общего применения: меню, навигация, работа с БД, шаблонизаторы...

А теперь всё вместе

После приведённых рассуждений можно уже попытаться дать определение идеальному фреймворку. «Конструктивное» определение – по способу создания.

Идеальный фреймворк – это папка /home/framework, куда по рельсам (по определённым правилам) время от времени выезжают общие элементы разных сайтов (сайты худеют, а фреймворк растёт). Рельсы (правила и принципы обобщения) являются частью фреймворка. Принципы, упомянутые в этой и предыдущей (http://dn.ir2.ru/ideal_framework.aspx) статьях, можно уже расположить в порядке важности:

Детальная обработка ошибок (без этого условия процесс просто не пойдёт).
Высокая скорость работы (обычно это = «экономия серверных ресурсов»).
Стремление к изоляции отдельных блоков кода (для воспроизводимости) – настолько, насколько это не противоречит второму принципу.
Хирургическая точность работы с HTTP-протоколом (никакой небрежности!) – требование в значительной степени эстетическое, так как фатальных ошибок при его невыполнении не возникает. Но в нашем фреймворке оно будет обязательно (такова, если хотите, прихоть автора).
Принцип-заглушка (без него тоже было бы трудно работать): если принципы и правила чего-то жёстко не требуют, и возникает сомнение, брось монетку для правильного выбора.

Значительная часть правил нашего фреймворка формируется по последнему принципу, то есть произвольно – правила являются просто договорённостями. И вот первое такое правило: папка, куда ведут рельсы, называется вовсе не framework, а ir2.sys. Второе: папка находится где угодно, но выше всех сайтов – из сайта её ищет специальная функция lib_find простым перебором всех вышестоящих папок. Строительство рельсов начинается с небольшого парадокса: две первые функции (lib_find и __autoload) не могут уехать «наверх» по рельсам, потому что они – первые шпалы для укладываемых рельсов; эти функции тупо дублируются на каждом сайте.

Третье: все настройки находятся в файле site.ini. Настройки, которые зависят от вычислений PHP, находятся где попало: это, например, база данных, имя которой должно составляться из двух строковых значений (включает префикс, зависящий от хостинга).

Четвёртое: файлы (скрипты), определяющие особенности конкретного сайта, находятся в папке <site_root>/exe (site_root – главная папка сайта, где находится index.php). Большинство файлов в корневой папке сайта не определяют особенности сайта, а принадлежат фреймворку: это и файл index.php, и файлы ErrorDocument, и библиотеки classes.css и common.js... Общие для всех сайтов файлы хранятся в папке ir2.sys/common_files и обновляются на сайтах централизованно, по системе, описанной в статье http://dn.ir2.ru/synhro-js-css.aspx. То есть общие файлы не следует изменять на самом сайте. Иначе пп.

Дальше уже начинается такая мелочь, такая куча подробностей, что проще показать рукой, чем рассказывать. Но показывать пока рано (не готово).

D.M., admin

Читать все комментарии (0)

Идеальный фреймворк (продолжение)

А теперь всё вместе

Добавить комментарий: