nautiluszverb
Новичок
Сборка и компановка общего дизайна страницы
здравствуйте
народ, интересует кто и как собирает конечную страницу, которая может включать вывод (данные) из нескольких разных модулей на нашем сайте.
например, пользователь передал www.somesite/news/21032008/hot-news
отработал модуль новостей и сгенерил контент ИМЕННО новостей согласно бизнес-логики для этого урла (или мета данные, в случае Two Stage View, или без привязки к паттернам, просто некий XML-маркап текст, который после преобразуется в конечный xhtml, будет содержать результат работы МОДУЛЯ НОВОСТЕЙ ).
Далее, нам надо "собрать" страницу, следующего вида (дефолтовый шаблон рендеринга паги, для которой не задан свой, перекрывающий дефолтовый)
- шапка - меню, определяемая контекстом новостей,
- слева - короткий список некой продукции,
- по центу - результат именно содержащий новости (то есть то, что и запросил пользователь - как бы главная часть) справа - там, скажем туча тегов, чуть ниже её (тучи) курсы, котировки и прочая как-бы "нужная" пользаку информация
- подвал - всякая прочая инфа - не суть важно (например - последние посты из форума)
Интуитивно понятно, что это вылитый паттерн Composite, но.... я на 100% уверен, что этой технологии (сборка конечной HTML страницы на основе реpультата работы различных сервисов сайта) уже придумали название и портировали сами принципы к идеологически верным решениям PHP (например, Явовский Composite View, мне не нравится, так как он более ближе к Яве, все представления сами решают какое подпредставление включать etc)
я делаю это следующим способом - Front Controller, на основе некой фабрики конфигураций сервисов (модулей), на одном из этапов построения цепочки фильтров, добавляет некий "Post" фильтр-компановщик, отрабатывающий после диспатчинга результата работы команд (или команды), вызываемых Application Controller-ом.
Когда вызван этот Post-фильтр, априори предполагается, что основная бизнес-логика отработала, Responce содержит бизнес-данные, и можно собирать страницу, на основе конфига отображения, для данного модуля, то есть фильтр начинает "дёргать" прочие сервисы сайта на предмет получения неких данных - как бы эмулируя запросы пользователя, с дефолтовыми значениями параметров для соотв. команд.
Однако, в силу вышеописанной причины, этот подход мне кажется слегка "велосипедно-изобретательским" и не достаточно гибким (взять хоть бы тот факт, что фильтр-компановщик должен знать интерфейсы всех прочих модулей...).
Вобщем, подскажите пожалуйста, есть ли какой-либо способ, наиболее предпочтительный при формировании компохитных страниц.
большое спасибо.
здравствуйте
народ, интересует кто и как собирает конечную страницу, которая может включать вывод (данные) из нескольких разных модулей на нашем сайте.
например, пользователь передал www.somesite/news/21032008/hot-news
отработал модуль новостей и сгенерил контент ИМЕННО новостей согласно бизнес-логики для этого урла (или мета данные, в случае Two Stage View, или без привязки к паттернам, просто некий XML-маркап текст, который после преобразуется в конечный xhtml, будет содержать результат работы МОДУЛЯ НОВОСТЕЙ ).
Далее, нам надо "собрать" страницу, следующего вида (дефолтовый шаблон рендеринга паги, для которой не задан свой, перекрывающий дефолтовый)
- шапка - меню, определяемая контекстом новостей,
- слева - короткий список некой продукции,
- по центу - результат именно содержащий новости (то есть то, что и запросил пользователь - как бы главная часть) справа - там, скажем туча тегов, чуть ниже её (тучи) курсы, котировки и прочая как-бы "нужная" пользаку информация
- подвал - всякая прочая инфа - не суть важно (например - последние посты из форума)
Интуитивно понятно, что это вылитый паттерн Composite, но.... я на 100% уверен, что этой технологии (сборка конечной HTML страницы на основе реpультата работы различных сервисов сайта) уже придумали название и портировали сами принципы к идеологически верным решениям PHP (например, Явовский Composite View, мне не нравится, так как он более ближе к Яве, все представления сами решают какое подпредставление включать etc)
я делаю это следующим способом - Front Controller, на основе некой фабрики конфигураций сервисов (модулей), на одном из этапов построения цепочки фильтров, добавляет некий "Post" фильтр-компановщик, отрабатывающий после диспатчинга результата работы команд (или команды), вызываемых Application Controller-ом.
Когда вызван этот Post-фильтр, априори предполагается, что основная бизнес-логика отработала, Responce содержит бизнес-данные, и можно собирать страницу, на основе конфига отображения, для данного модуля, то есть фильтр начинает "дёргать" прочие сервисы сайта на предмет получения неких данных - как бы эмулируя запросы пользователя, с дефолтовыми значениями параметров для соотв. команд.
Однако, в силу вышеописанной причины, этот подход мне кажется слегка "велосипедно-изобретательским" и не достаточно гибким (взять хоть бы тот факт, что фильтр-компановщик должен знать интерфейсы всех прочих модулей...).
Вобщем, подскажите пожалуйста, есть ли какой-либо способ, наиболее предпочтительный при формировании компохитных страниц.
большое спасибо.
