Изменения

Перейти к: навигация, поиск

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

4952 байта убрано, 12:43, 20 июня 2016
В данный момент я ([[Участник:VitaliyFilippov|VitaliyFilippov]] 16:33, 12 июля 2009 (UTC)) создаю некую Новую Платформу для веб-разработки. Идея её, как всегда, частично идёт «от противного» — несмотря на то, что Платформа, Выросшая Из [[Vitaphoto]], вполне жизнеспособна, юзабельна и даже содержит некоторые разумные идеи, она всё-таки неидеальна в использовании.
== Цель ==
Пусть наше приложение состоит из различных модулей, которые реализованы реюзабельными, то есть фактически '''модули не знают состав веб-приложения, в котором исполняются''', и из некоторого «диспетчера», который знает, какие страницы из каких модулей «составляются». Модули производят некоторую обработку и возвращают некоторые данные, попадающие в шаблонизатор. Шаблонизатор же на основе этих данных с помощью простейших (''только'' простейших) операций генерирует страницу. В целом можно считать, что каждой странице соответствует один шаблон, опционально включающий в себя другие шаблоны.
Итак, на входе мы имеем HTTP-запрос некоторой страницы. Не суть, каким образом описывается её адрес — пусть это будет просто строка. Запрос попадает в диспетчер, который на основании адреса выясняет, к какому типу страницы относится запрос, и вызывает обработчик конкретного типа страницы. В простейшем случае данный обработчик — просто функция диспетчера, делающая в определённой последовательности вызовы к различным модулям и составляющая результирующий набор информации для передачи в шаблонизатор. А способы разбора адресов страниц, в общем случае, могут кардинально различаться: например, можно рассмотреть две крайности — наивный способ, распознающий имя скрипта и параметры запроса (''/script.php?key=value&key=value&key=value''), или же ссылки, состояющие из названия материала и даты создания, «как завещал великий W3C» (''/2009-07-05-modular-web-development.html'')в статье «[http://www.w3.org/Provider/Style/URI Hypertext Style: Cool URIs don’t change]».
Тем временем модулям в процессе обработки страницы может захотеться (и обычно хочется) сослаться на другую страницу — например, модуль, отображающий список тем форума, вероятно, может изъявить желание сформировать ссылки на отдельные темы, а также на профили пользователей и т. п. И вот здесь-то мы и сталкиваемся с проблемой! Модуль не знает, из каких страниц состоит приложение, и даже не знает, как генерируются ссылки на те или страницы — и поэтому не может сослаться на другую страницу. То есть, обработка получается «односторонная».
Как решать данную проблему? Можно, например, запретить модулям делать перенаправления между страницами сайта кроме тех случаев, когда ''тип'' целевой страницы по-настоящему фиксирован — например, если это всегда перенаправление на страницу обработчика OpenID, а вместо редиректа возвращать определённые данные, по котором диспетчер сможет определить нужное действие. Можно даже возложить формирование перенаправлений на шаблонизатор, введя функции перенаправления, для их вызова из шаблонов.
… Вот и наступил момент, когда сохранение модульности и гибкости повлёк повлекло за собой уже достаточно серьёзное усложнение логики использования модулей — логика стала разнесена по нескольким уровням.
Вероятно, в Новой Платформе данный подход таки и будет опробован, но вполне возможно, что приложение в итоге получится «адовое», а вовсе не удобное.
== Идеи == === Старые, проверенные === Во-первых, доказавшие свою рациональность идеи из старой платформы: Приложение делится на модули. Для вывода кода страниц используется [[VMX-Template|шаблонизаторКатегория:Sway]] своей разработки. Причём, он специально сделан максимально простым, дабы избежать анти-паттернов разработки, к которым подталкивает [[TemplateToolkit|TemplateКатегория::ToolkitАрхив]], а именно, к перемещению 50 % логики в шаблоны. Примеры того, где так происходит — Bugzilla, Vsem.ru. Используется шаблонизатор, созданный когда-то по мотивам шаблонизатора phpBB2, о чём напоминает синтаксис. Умеет буквально 5 вещей: циклы, IF’ы, INCLUDE (включение другого шаблона), подстановки выражений в код, присваивания. Данные в шаблон передаются просто Perl-хешем. Конфигурация приложения представляет собой вложенный хеш, хранимый просто в виде Perl-кода. === Противоположности старым, нерациональным === Во-вторых, идеи, созданные «от противного» по отношению к старой платформе: Модули теперь создаются по требованию, а не все сразу при старте приложения. Поэтому и modules_allow и modules_deny в конфигурации больше нет. Обработчик приложения делает фактически только eval {} для отлова исключений и подключение директорий @INC. В старой платформе обработчик делал Много Чего, в результате появлялись жёсткие завязки на различные моменты. Теперь же платформа от них свободна, и вся функциональность, имевшая жёсткие завязки, теперь разнесена по модулям, и её можно как использовать, так и '''не''' использовать: # Нет виртхостов (хотя они реализуемы) — идея размещения нескольких сайтов в одной базе данных показала свою несостоятельность;# Нет завязки на вызов метода render() у модулей, то есть методы обработки можно создавать любые по желанию;# Нет конфигурации «последовательностей модулей», то есть вызовы разных модулей можно комбинировать в коде как душе угодно;# Нет хеша имён таблиц, сопоставляющего «реальные» таблицы «виртуальным»;# Нет завязки на регулярные выражения в разборе URI, а точнее, нет вообще никакой завязки в разборе URI, как и самого стандартного разбора URI, кроме «страница?параметры»;# Нет завязки на обязательное соединение с БД; Стандартные библиотечные модули больше не предоставляют собой «готовых страниц» — каждый модуль теперь являет собой просто библиотеку функций, а функции, выводившие что-то в шаблон, теперь просто возвращают хеш, который можно подставлять, куда душе угодно. === Новые === И в-третьих, новые идеи: Все обращения к БД из библиотечных модулей теперь оборачиваются в функции и живут в Sway::db::, а рядом с ними лежат SQL дампы нужных им таблиц; аналогично обращениям к БД делаются абстракции других операций — иногда хранения (например сессий в кэше), иногда преобразования (например текста сообщений форума). Версионирование БД. Поддержка Funq. EmLog — простой интерфейс, этакий RSS с PUSH’ем для блогов, в качестве транспорта использующий Email.

Навигация