QQQ
Новичок
Архитектура, где отображение - главное. Имеет смысл?
Думаю идея не нова, но я нигде не видел развёрнутого описания данной архитектуры.
Рассуждения мои чисто теоритические, я не занимаюсь реализацией подобного, просто идея показалась мне интересной, хочется поделиться ей и выслушать другие мнения на этот счёт.
Как происходит работа классического MVC веб приложения? (рассматривать всё буду упрощённо)
1) Парсинг http запроса, на основании которого происходит вызов нужного модуля/конструктора
2) Отработка конструктора изменение/извлечение данных
3) Подстановка данных в шаблон и вывод
Я думаю не секрет, что большинство html страниц можно разделить на блоки, генерация которых происходит на основе данных, которые мало связанны между собой. Часто даже используется SSI, для отображения в целой странице различных блоков.
Что, если пойти от обратного?
Имеем шаблон отображения, что-то типа (названия функций и т.д. тупо схематично для примера):
1) На основании http запроса определяем layout отображения + необходимые ему данные
2) Рендерим шаблон, попутно вызывая контроллеры необходимых блоков
То-есть из примера 1 (классического MVC) пункты 2 и 3 делаем за один, причём начиная с 3го?
ps: При обновление данных вызывается сразу нужный контроллер, минуя layout. Всё равно при обновлении ничего не должно отдаваться, кроме как json/xml или редиректа Header('Location: ...)
pps: для не html отображений (json например) использовать следующие шаблоны:
Хотелось бы послушать мнения на данный счёт
Думаю идея не нова, но я нигде не видел развёрнутого описания данной архитектуры.
Рассуждения мои чисто теоритические, я не занимаюсь реализацией подобного, просто идея показалась мне интересной, хочется поделиться ей и выслушать другие мнения на этот счёт.
Как происходит работа классического MVC веб приложения? (рассматривать всё буду упрощённо)
1) Парсинг http запроса, на основании которого происходит вызов нужного модуля/конструктора
2) Отработка конструктора изменение/извлечение данных
3) Подстановка данных в шаблон и вывод
Я думаю не секрет, что большинство html страниц можно разделить на блоки, генерация которых происходит на основе данных, которые мало связанны между собой. Часто даже используется SSI, для отображения в целой странице различных блоков.
Что, если пойти от обратного?
Имеем шаблон отображения, что-то типа (названия функций и т.д. тупо схематично для примера):
Код:
<html>
<head>
<title><?=$this->set_title($this->title)?></title>
</head>
<body>
<?=$this->render('header.tpl')?>
<div id="menu"><?=$this->render('menu.tpl', App::call_controller('main_menu'))?></div>
<div id="left_column">
<?=$this->render('sub_menu.tpl', App::call_controller('sub_menu'))?>
<?=$this->render('adware.tpl', App::call_controller('adware'))?>
</div>
<div id="content">
<?=$this->render('content.tpl', App::call_controller($this->page_controller))?>
</div>
<?=$this->render('footer.tpl')?>
</body>
</html>1) На основании http запроса определяем layout отображения + необходимые ему данные
2) Рендерим шаблон, попутно вызывая контроллеры необходимых блоков
То-есть из примера 1 (классического MVC) пункты 2 и 3 делаем за один, причём начиная с 3го?
ps: При обновление данных вызывается сразу нужный контроллер, минуя layout. Всё равно при обновлении ничего не должно отдаваться, кроме как json/xml или редиректа Header('Location: ...)
pps: для не html отображений (json например) использовать следующие шаблоны:
Код:
$Return->title = $this->set_title($this->title);
$Return->menu = App::call_controller('menu');
$Return->content = App::call_controller($this->page_controller);Хотелось бы послушать мнения на данный счёт
