Изменения

В данный момент я ([[Участник: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]».

Для вывода кода страниц используется [[VMX-Template|шаблонизатор]] своей разработки. ПричёмТем временем модулям в процессе обработки страницы может захотеться (и обычно хочется) сослаться на другую страницу — например, он специально сделан максимально простыммодуль, дабы избежать анти-паттернов разработкиотображающий список тем форума, вероятно, к которым подталкивает [[TemplateToolkit|Template::Toolkit]]может изъявить желание сформировать ссылки на отдельные темы, а именно, к перемещению 50 % логики в шаблонытакже на профили пользователей и т. Примеры того, где так происходит — Bugzilla, Vsem п.ru. Используется шаблонизатор, созданный когдаИ вот здесь-то по мотивам шаблонизатора phpBB2мы и сталкиваемся с проблемой! Модуль не знает, о чём напоминает синтаксис. Умеет буквально 5 вещей: циклыиз каких страниц состоит приложение, IF’ыи даже не знает, INCLUDE (включение другого шаблона)как генерируются ссылки на те или страницы — и поэтому не может сослаться на другую страницу. То есть, подстановки выражений в код, присваивания; Данные в шаблон передаются просто Perl-хешем;обработка получается «односторонная».

Конфигурация приложения представляет собой вложенный хеш, хранимый просто в виде Perl<graph>digraph G { rankdir=LR; "HTTP-запрос" -> Страница1; "HTTP-запрос" -> Страница2; "HTTP-запрос" -> Страница3; Страница1 -> Модуль1; Страница1 -> Модуль2; Страница2 -> Модуль2; Страница2 -> Модуль3; Модуль2 -> "Ссылка на страницу2 -кодаКАК?";}</graph>

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

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

Модули теперь создаются по требованиюНо и здесь мы снова встречаем проблемы — во-первых, а не все сразу при старте приложения. Поэтому код усложняется, так как помимо уровня диспетчера, составляющего сами ссылки, появляется ещё и modules_allow и modules_deny необходимость указывать все параметры в конфигурации больше нетшаблонах. А во-вторых, наступает время вспомнить о том, что действие, осуществляемое модулем, не обязательно приводит к генерации HTML-страницы — ещё, например, существует такая вещь, как ''перенаправление''. Шаблоны при этом не используются, а ссылки требуются.

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

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

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

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