Просмотр исходного текста страницы Проблема модульной веб-разработки

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

Тем временем модулям в процессе обработки страницы может захотеться (и обычно хочется) сослаться на другую страницу — например, модуль, отображающий список тем форума, вероятно, может изъявить желание сформировать ссылки на отдельные темы, а также на профили пользователей и т. п. И вот здесь-то мы и сталкиваемся с проблемой! Модуль не знает, из каких страниц состоит приложение, и даже не знает, как генерируются ссылки на те или страницы — и поэтому не может сослаться на другую страницу. То есть, обработка получается «односторонная».

<graph>
digraph G {
  rankdir=LR;
  "HTTP-запрос" -> Страница1;
  "HTTP-запрос" -> Страница2;
  "HTTP-запрос" -> Страница3;
  Страница1 -> Модуль1;
  Страница1 -> Модуль2;
  Страница2 -> Модуль2;
  Страница2 -> Модуль3;
  Модуль2 -> "Ссылка на страницу2 - КАК?";
}
</graph>

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

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

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

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

… Вот и наступил момент, когда сохранение модульности и гибкости повлекло за собой уже достаточно серьёзное усложнение логики использования модулей — логика стала разнесена по нескольким уровням.

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

[[Категория:Sway]]
[[Категория:Архив]]