В данный момент я ([[Участник:VitaliyFilippov|VitaliyFilippov]] 16:33, 12 июля 2009 (UTC)) создаю некую Новую Платформу для веб-разработки. Идея её, как всегда, частично идёт «от противного» — несмотря на то, что Платформа, Выросшая Из [[Vitaphoto]], вполне жизнеспособна, юзабельна и даже содержит некоторые разумные идеи, она всё-таки неидеальна в использовании.
== Цель ==
# простоты и гибкости в использовании.
== Идеи Проблема ==
ВоМодульная веб-первых, доказавшие свою рациональность идеи из старой платформы:разработка имеет одну очень неприятную идеологическую проблему.
# Приложение делится на Пусть наше приложение состоит из различных модулей, которые реализованы реюзабельными, то есть фактически '''модули;# Для вывода кода страниц используется [[VMXне знают состав веб-Template|шаблонизатор]] своей разработки. Причёмприложения, он специально сделан максимально простымв котором исполняются''', дабы избежать анти-паттернов разработкии из некоторого «диспетчера», к которым подталкивает [[TemplateToolkit|Template::Toolkit]]который знает, а именнокакие страницы из каких модулей «составляются». Модули производят некоторую обработку и возвращают некоторые данные, к перемещению 50 % логики попадающие в шаблоны. Примеры того, где так происходит — Bugzilla, Vsem.ru. Используется шаблонизатор, созданный когда-то по мотивам шаблонизатора phpBB2, о чём напоминает синтаксис. Умеет буквально 5 вещей: циклы, IF’ы, INCLUDE Шаблонизатор же на основе этих данных с помощью простейших (включение другого шаблона''только'' простейших)операций генерирует страницу. В целом можно считать, подстановки выражений в код, присваивания; Данные в что каждой странице соответствует один шаблон передаются просто Perl-хешем;# Конфигурация приложения представляет собой вложенный хеш, хранимый просто опционально включающий в виде Perl-кода;себя другие шаблоны.
ВоИтак, на входе мы имеем 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]».
# Модули теперь создаются по требованию, а не все сразу при старте приложения. Поэтому и modules_allow и modules_deny Тем временем модулям в конфигурации больше нет;# Обработчик приложения делает фактически только eval {} для отлова исключений процессе обработки страницы может захотеться (и подключение директорий @INC. В старой платформе обработчик делал Много Чего, в результате появлялись жёсткие завязки на некоторые идеи:## Нет виртхостов (хотя они реализуемыобычно хочется) — идея размещения нескольких сайтов в одной базе данных показала свою несостоятельность;## Нет завязки сослаться на вызов метода render() у модулейдругую страницу — например, то есть методы обработки можно создавать любые по желанию;## Нет конфигурации «последовательностей модулей»модуль, то есть вызовы разных модулей можно комбинировать в коде как душе угодно;## Нет хеша имён таблицотображающий список тем форума, сопоставляющего «реальные» таблицы «виртуальным»;## Нет завязки вероятно, может изъявить желание сформировать ссылки на регулярные выражения в разборе URIотдельные темы, а точнее, нет вообще никакой завязки в разборе URI, как также на профили пользователей и т. п. И вот здесь-то мы и самого стандартного разбора URI, кроме «страница?параметры»;## Нет завязки на обязательное соединение сталкиваемся с БД;# Вся функциональностьпроблемой! Модуль не знает, имевшая жёсткие завязкииз каких страниц состоит приложение, теперь разнесена по модулями даже не знает, и её можно как использовать, так генерируются ссылки на те или страницы — и '''поэтому не''' использовать;# Стандартные библиотечные модули больше не предоставляют собой «готовых страниц» — каждый модуль теперь являет собой просто библиотеку функцийможет сослаться на другую страницу. То есть, а функции, выводившие что-то в шаблон, теперь просто возвращают хеш, который можно подставлять, куда душе угодно;обработка получается «односторонная».
И в<graph>digraph G { rankdir=LR; "HTTP-третьих, новые идеи:запрос" -> Страница1; "HTTP-запрос" -> Страница2; "HTTP-запрос" -> Страница3; Страница1 -> Модуль1; Страница1 -> Модуль2; Страница2 -> Модуль2; Страница2 -> Модуль3; Модуль2 -> "Ссылка на страницу2 - КАК?";}</graph>
# Все обращения к БД из библиотечных Для решения проблемы сразу напрашивается создание отдельного метода диспетчера, который будет осуществлять обратное преобразование — генерировать ссылки на страницы, например, на основе имени типа страницы и параметров. Но если сделать именно так, появляются ''типы страниц'', жёстко заданные в коде модулей теперь оборачиваются , которые на них ссылаются, и общая степень гибкости уменьшается. Сразу напрашивается логичная идея — значение ссылки зависит от её ''расположения'' на странице. А из неё сразу следует ещё одна идея — оставить генерацию ссылок на откуп шаблонизатору — формировать ссылки прямо в функции шаблонах, потому что шаблоны, в отличие от модулей, уже знают общий состав приложения. Не забывая про необходимость удобства системы генерации ссылок для поддержки и изменения, получаем идею генерации ссылок по той же схеме — из типа страницы и параметров, но уже из шаблонов. Но и здесь мы снова встречаем проблемы — во-первых, код усложняется, так как помимо уровня диспетчера, составляющего сами ссылки, появляется ещё и живут необходимость указывать все параметры в Sway::db::шаблонах. А во-вторых, наступает время вспомнить о том, что действие, осуществляемое модулем, не обязательно приводит к генерации HTML-страницы — ещё, например, существует такая вещь, как ''перенаправление''. Шаблоны при этом не используются, а рядом с ними лежат SQL дампы нужных им таблиц;ссылки требуются.# Аналогично обращениям к БД делаются абстракции других операций — иногда хранения (Как решать данную проблему? Можно, например сессий в кэше), иногда преобразования (запретить модулям делать перенаправления между страницами сайта кроме тех случаев, когда ''тип'' целевой страницы по-настоящему фиксирован — например текста сообщений форума);, если это всегда перенаправление на страницу обработчика OpenID, а вместо редиректа возвращать определённые данные, по котором диспетчер сможет определить нужное действие. Можно даже возложить формирование перенаправлений на шаблонизатор, введя функции перенаправления, для их вызова из шаблонов.# Версионирование БД;# Поддержка Funq;… Вот и наступил момент, когда сохранение модульности и гибкости повлекло за собой уже достаточно серьёзное усложнение логики использования модулей — логика стала разнесена по нескольким уровням.# EmLog — простой интерфейсВероятно, этакий RSS с PUSH’ем для блоговв Новой Платформе данный подход таки и будет опробован, но вполне возможно, что приложение в качестве транспорта использующий Emailитоге получится «адовое», а вовсе не удобное. [[Категория:Sway]][[Категория:Архив]]
