Comments 18
Любопытно. Как раз в данный момент тоже реализуем свою CMS. Некоторые вещи похожи на предложенный вами концепт.
Не до конца понятно зачем так много контроллеров. Либо поясните что вы подразумеваете под контролером? Например, в RoR это реализовано очень просто и ясно. В обработчике действия контроллера выбирается какой вид отдавать пользователю (в зависимости от типа пользовательского агента).
На мой взгляд если вы хотите одни и те же данные отображать на разных устройствах и в разных браузерах, то тут лучше подойдет XSLT. Определяете возможности браузера и трансформируете данные нужным шаблоном!
На мой взгляд подобное разделение контента должно идти не в контроллере, а в слое представления.
Например как в фрейворке Symfony в котором реализована следуюшая схема:
Каждому действию в контролере соответствует свой шаблон, действию bla будет соответствовать шаблон Blasuccess.php
версии действия bla для json запроса соответствует шаблон Blasuccess.json.php.
Во время обработки запроса контроллер оперделяет по хедерам http запроса тип ожидаемого содержимого и использует соответствуюший шаблон.
Подобная модель больше соответствует патерну MVC.
Например как в фрейворке Symfony в котором реализована следуюшая схема:
Каждому действию в контролере соответствует свой шаблон, действию bla будет соответствовать шаблон Blasuccess.php
версии действия bla для json запроса соответствует шаблон Blasuccess.json.php.
Во время обработки запроса контроллер оперделяет по хедерам http запроса тип ожидаемого содержимого и использует соответствуюший шаблон.
Подобная модель больше соответствует патерну MVC.
Вообще то я не далеко ушёл от паттерна MVC. Изначально у меня так и было это реализовано. Данная идея относится к случаю, когда нужно не просто представить данные в разных форматах, а по разному реагировать на события. Например, в основном виде нужно сделать редирект после внесения данных в базу, в ajax нужно просто вывести сообщение, в мобильной версии вообще не сохранять данные, а просто проанализировать.
В данном случае одной постановкой шаблонов не разберёшься.
В данном случае одной постановкой шаблонов не разберёшься.
Zend Framework это не CMS, это CMF!
И еше не счет изменений в Zend.
Ради бога не лазьте в ядро!!! используйте наследование как способ изменения поведения классов, у нас на работе был случай когда пришлось доделывать чужой проект на зенде, в нем были внесены изменения во множество классов фрейворка, изза чего отлов ошибок и попытка перехода на новую версию превратились в сущий кошмар(
Ради бога не лазьте в ядро!!! используйте наследование как способ изменения поведения классов, у нас на работе был случай когда пришлось доделывать чужой проект на зенде, в нем были внесены изменения во множество классов фрейворка, изза чего отлов ошибок и попытка перехода на новую версию превратились в сущий кошмар(
Нужно ридонли поставить на эти файлы XD чтобы не повадно было.
Вот, вот именно поэтому существует такая чтука как интерфейсы, которые надо поддерживать. Которых в зенде полно. Убивать надо за то, что они с вами сделали…
Вот, вот именно поэтому существует такая чтука как интерфейсы, которые надо поддерживать. Которых в зенде полно. Убивать надо за то, что они с вами сделали…
Имелась в виду CMS, основанная на фрэймфорке типа Zend Framework.
Я это вижу так.
Прежде чем обработчик дойдет до исполнения контроллера ему предстоит понять, какие данные пользователь хочет и что пользователь передаёт, далее когда наступает момент выполнения контроллера, система определяет на, что данный пользователь передал Ajax запрос либо это с мобильного телефона. Контроллер в свою очередь говорит, что он передаёт свою работу в View который пытается загрузить к примеру вьюшку под названием Index далее:
view
— rss
—— index
— mobile
—— index
— ajax
—— index
Вью подставляет префикс к инклуду и мы получаем тот вью который нам нужен, в зависимости от запроса инклуды будут такие
/view/rss/index — если RSS
/view/mobile/index если mobile и так далее.
Прежде чем обработчик дойдет до исполнения контроллера ему предстоит понять, какие данные пользователь хочет и что пользователь передаёт, далее когда наступает момент выполнения контроллера, система определяет на, что данный пользователь передал Ajax запрос либо это с мобильного телефона. Контроллер в свою очередь говорит, что он передаёт свою работу в View который пытается загрузить к примеру вьюшку под названием Index далее:
view
— rss
—— index
— mobile
—— index
— ajax
—— index
Вью подставляет префикс к инклуду и мы получаем тот вью который нам нужен, в зависимости от запроса инклуды будут такие
/view/rss/index — если RSS
/view/mobile/index если mobile и так далее.
В принципе, тоже самое что и в симфони, только слегка видоизмененное)
В Zend Framework для подобных целей есть экшен хелпер ContextSwitch.
А мысли об изменении чего либо в ядре фреймворка сразу отбросьте. Кому нужны эти проблемы с отладкой и обновлением :). Да это и не нужно. Zend Framework в плане изменения поведения очень гибок.
А мысли об изменении чего либо в ядре фреймворка сразу отбросьте. Кому нужны эти проблемы с отладкой и обновлением :). Да это и не нужно. Zend Framework в плане изменения поведения очень гибок.
Совершенно согласен, просто моя CMS не основывается на Zend Framework, а кое чем напоминает её структуру. Каким образом кто-то будет вносить изменения в существующие фрэймворки это сугубо личное дело. Будь это хелпер, наследование или изменение ядра. Я не хочу кого-то предостерегать от неправильных действий, это всего лишь идея.
Sign up to leave a comment.
Разработка CMS