Проблема модульной веб-разработки

Ссылки сюда (1) →

В данный момент я (VitaliyFilippov 16:33, 12 июля 2009 (UTC)) создаю некую Новую Платформу для веб-разработки. Идея её, как всегда, частично идёт «от противного» — несмотря на то, что Платформа, Выросшая Из Vitaphoto, вполне жизнеспособна, юзабельна и даже содержит некоторые разумные идеи, она всё-таки неидеальна в использовании.

Цель

Цель — добиться максимальных:

1. модульности
2. возможности повторного использования кода
3. простоты и гибкости в использовании.

Идеи

Во-первых, доказавшие свою рациональность идеи из старой платформы:

1. Приложение делится на модули;
2. Для вывода кода страниц используется шаблонизатор своей разработки. Причём, он специально сделан максимально простым, дабы избежать анти-паттернов разработки, к которым подталкивает Toolkit, а именно, к перемещению 50 % логики в шаблоны. Примеры того, где так происходит — Bugzilla, Vsem.ru. Используется шаблонизатор, созданный когда-то по мотивам шаблонизатора phpBB2, о чём напоминает синтаксис. Умеет буквально 5 вещей: циклы, IF’ы, INCLUDE (включение другого шаблона), подстановки выражений в код, присваивания; Данные в шаблон передаются просто Perl-хешем;
3. Конфигурация приложения представляет собой вложенный хеш, хранимый просто в виде Perl-кода;

Во-вторых, идеи, созданные «от противного» по отношению к старой платформе:

1. Модули теперь создаются по требованию, а не все сразу при старте приложения. Поэтому и modules_allow и modules_deny в конфигурации больше нет;
2. Обработчик приложения делает фактически только eval {} для отлова исключений и подключение директорий @INC. В старой платформе обработчик делал Много Чего, в результате появлялись жёсткие завязки на некоторые идеи:
   1. Нет виртхостов (хотя они реализуемы) — идея размещения нескольких сайтов в одной базе данных показала свою несостоятельность;
   2. Нет завязки на вызов метода render() у модулей, то есть методы обработки можно создавать любые по желанию;
   3. Нет конфигурации «последовательностей модулей», то есть вызовы разных модулей можно комбинировать в коде как душе угодно;
   4. Нет хеша имён таблиц, сопоставляющего «реальные» таблицы «виртуальным»;
   5. Нет завязки на регулярные выражения в разборе URI, а точнее, нет вообще никакой завязки в разборе URI, как и самого стандартного разбора URI, кроме «страница?параметры»;
   6. Нет завязки на обязательное соединение с БД;
3. Вся функциональность, имевшая жёсткие завязки, теперь разнесена по модулям, и её можно как использовать, так и не использовать;
4. Стандартные библиотечные модули больше не предоставляют собой «готовых страниц» — каждый модуль теперь являет собой просто библиотеку функций, а функции, выводившие что-то в шаблон, теперь просто возвращают хеш, который можно подставлять, куда душе угодно;

И в-третьих, новые идеи:

1. Все обращения к БД из библиотечных модулей теперь оборачиваются в функции и живут в Sway::db::, а рядом с ними лежат SQL дампы нужных им таблиц;
2. Аналогично обращениям к БД делаются абстракции других операций — иногда хранения (например сессий в кэше), иногда преобразования (например текста сообщений форума);
3. Версионирование БД;
4. Поддержка Funq;
5. EmLog — простой интерфейс, этакий RSS с PUSH’ем для блогов, в качестве транспорта использующий Email.