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

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

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

Цель

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

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

Идеи

Старые, проверенные

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

Приложение делится на модули.

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

Конфигурация приложения представляет собой вложенный хеш, хранимый просто в виде Perl-кода;

Противоположности старым, нерациональным

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

Модули теперь создаются по требованию, а не все сразу при старте приложения. Поэтому и modules_allow и modules_deny в конфигурации больше нет.

Обработчик приложения делает фактически только eval {} для отлова исключений и подключение директорий @INC. В старой платформе обработчик делал Много Чего, в результате появлялись жёсткие завязки на различные моменты. Теперь же платформа от них свободна, и вся функциональность, имевшая жёсткие завязки, теперь разнесена по модулям, и её можно как использовать, так и не использовать:

1. Нет виртхостов (хотя они реализуемы) — идея размещения нескольких сайтов в одной базе данных показала свою несостоятельность;
2. Нет завязки на вызов метода render() у модулей, то есть методы обработки можно создавать любые по желанию;
3. Нет конфигурации «последовательностей модулей», то есть вызовы разных модулей можно комбинировать в коде как душе угодно;
4. Нет хеша имён таблиц, сопоставляющего «реальные» таблицы «виртуальным»;
5. Нет завязки на регулярные выражения в разборе URI, а точнее, нет вообще никакой завязки в разборе URI, как и самого стандартного разбора URI, кроме «страница?параметры»;
6. Нет завязки на обязательное соединение с БД;

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

Новые

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

Все обращения к БД из библиотечных модулей теперь оборачиваются в функции и живут в Sway::db::, а рядом с ними лежат SQL дампы нужных им таблиц; аналогично обращениям к БД делаются абстракции других операций — иногда хранения (например сессий в кэше), иногда преобразования (например текста сообщений форума).

Версионирование БД.

Поддержка Funq.

EmLog — простой интерфейс, этакий RSS с PUSH’ем для блогов, в качестве транспорта использующий Email.