Составление страницы в MVC

[player]

Составление страницы в MVC

Добрый день!

Решил сделать цмску по MVC, конечно наткнулся на проблему что в цмс нужно составлять вебстраницу из разных блоков - новостаня лента, разные блоки информации и тд. Логично что один контроллер, который отвечает за предоставление главного контента, не можеть заботиться о разных блоках.
Возникает вопрос, каким образом (вы считаете) лучше загружать это все в темплейт:

1. Загружаем контроллер
Вычислить все блоки (доп. контроллерами), сохранять как массивы/объекты
Начинать парсить главный темплейт
Подставлять блоки в темплейт

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

2. Загружаем "главный" контроллер
Начинаем парсить темплейт
В коде темплейта запрашиваем другие контроллеры, которые предоставляют блоки.

Здесь смущает что немного разбивается модель MVC, шаблон запрашивает разные информации.

Что думаете? Может быть есть другие версии. Как лучше сделать?

 

[С.]

Загружаем контроллер. Вычислить все блоки...

Какие "все"? Откуда контролер узнает, какие блоки надо "вычислять"?

смущает что немного разбивается модель MVC, шаблон запрашивает разные информации

В чем состоит "разбив"? Кто запрещал шаблону запрашивать?

 

[MuXaJIbI41981]

можно посмотреть как сделано в других фреймворках

можно например в шаблоне подключать компоненты (блоки дополнительные) , которые сами будут считывать необходимые данные для заполнения этого блока и подгружать его

 

[Beavis]

player
Вообще удобней второй вариант, но первый как то правильней...)

 

[player]

2 С.

Какие "все"? Откуда контролер узнает, какие блоки надо "вычислять"?

В том и прикол... я сам это написал потом. то ли дополнительно гдето сохранять список блоков, то ли еще както.
Этот вариант конечно както элегантнее звучит.

можно посмотреть как сделано в других фреймворках

Ну, здесь мнения конечно расходятся, критика ко всему есть, и везде комментарии пишут, что "делайте как считаете нужным"

в шаблоне подключать компоненты (блоки дополнительные)

То есть вызов опять же дополнительных контроллеров

 

[Alexandre]

2. Загружаем "главный" контроллер
Начинаем парсить темплейт
В коде темплейта запрашиваем другие контроллеры, которые предоставляют блоки.

активные шаблоны ни есть гуд, но это ИМХО

1. Загружаем контроллер
Вычислить все блоки (доп. контроллерами), сохранять как массивы/объекты
В этом способе смущает что все хранится в памяти...

а много там хронится? ты же не все свои контроллеры грузишь в память, а только те - которые необходимы?

 

[player]

а много там хронится? ты же не все свои контроллеры грузишь в память, а только те - которые необходимы?

ну да, только те что нужны. а что?

 

[С.]

то ли дополнительно гдето сохранять список блоков, то ли еще както.
Этот вариант конечно както элегантнее звучит.

Ну если ты считаешь, что перечислить блоки "где-то", потом их же в шаблоне, а потом возможно еще пару раз в разным местах будет элегантным решением, то в да, так можно.

 

[player]

Нет, я имею ввиду что вариант, что все заранее рендерится, кажется мне элегантным - единственная проблема это найти решение, откуда брать список блоков

-~{}~ 01.10.09 17:14:

Alexandre

активные шаблоны ни есть гуд

Так как тогда делать можно? В большинстве MVC фреймворков именно так и поступают, но мне тоже както не по душе

 

[Духовность™]

Автор поднял актуальную тему.

1. Загружаем контроллер
Вычислить все блоки (доп. контроллерами), сохранять как массивы/объекты
Начинать парсить главный темплейт
Подставлять блоки в темплейт

Это хорошая и правильная идея (активные шаблоны называется). Но попробуйте её реализовать. У меня не получилось сделать внятный, прозрачный механизм. Даже чисто теоретически. Вот моя тема про активные шаблоны, ушедшая далеко в офф.: http://phpclub.ru/talk/showthread.php?s=&threadid=113913&

Выросшая из проблемы как у Вас - http://phpclub.ru/talk/showthread.php?s=&threadid=112694

2. Загружаем "главный" контроллер
Начинаем парсить темплейт
В коде темплейта запрашиваем другие контроллеры, которые предоставляют блоки.

нет. Контроллер реагирует на событие - на HTTP запрос. Другие "контролеры", "предоставляющие блоки" - это уже не контроллеры. Это другой слой в приложении.


Какой я нашёл для себя выход? У меня все рюшечки, всё, за исключением основного контента, получает view слой, который не только представляет собой деюро шаблонизатор (PHP), но и запрашивает все дополнительные вещи.

Поясню.

Контроллер News отображает новость. Он лезет в БД и достает текст.

В этом контроллере инстанцируется слой View, а именно - класс ViewNews, который тупо знает, что нужно достать из базы, что бы вывести на странице.

Не красиво? Не правильно? Не знаю, может быть. Но иного выхода я не вижу. Только активные шаблоны.

 

[С.]

.

единственная проблема это найти решение, откуда брать список блоков

Да, действительно проблема в такой мелочи.

-~{}~ 01.10.09 21:21:

triumvirat, активным шаблоном является как раз пункт 2.
А пункт 1 является бредом сивой кобылы.

 

[Духовность™]

С.
ок

 

[Krishna]

ТруЪ MVC это когда контроллер обращается ко view и к модели, view к модели и ко view онли, модель к другим моделям.

Всё остальное - ересь

 

[Духовность™]

....

 

[john.brown]

Незнаю, на сколько оно кошерно, но у меня сделано так:
есть фронт контроллер, и есть модули с Action контроллерами. Сама страница строится на основе лайоут конфига, в котором прописан файл шаблона, блоки шаблона, и модуль/акция для каждого блока. При запросе разных модудей/акций могут использоваться разные лайоут конфиги (прописано в другом конфиге).

При вызове фронт конроллер смотрит запрошенный модуль/акцию, определяет, какой лайоут конфиг использовать, по нему определяет, какие модули/акции вызывать, и куда в шаблон распихивать результаты.

 

[player]

john.brown
То есть ты разделил страницы на лэйауты, при создании страницы админ выбирает, какой лэйаут он хочет использовать, и просто добавляет свой контент.
Мне этот подход очень нравится, потомучто сам весь день сегодня думал о чемто таком.

Или что делать если для другой темы сайта нужны дополнительные блоки, или другой порядок? Ты в конфиге просто перечисляеш блоки, или также и позицию их сразу задаеш?
Очень интересно, каким образом в темплейте располагаеш блоки?

 

[john.brown]

player
Ну не совсем так, если правильно тебя понял. У меня понятия "страница" нету (или оно оч расплывчато).

Суть в том, что при настройке сайта админ выбирает, что для вызова module=Articles&cmd=ArtList использовать layout1, а для module=Articles&cmd=FullArticle - layout2. Ну и есть лайоут по умолчанию для всего сайта, который используеться, если нет ничего другого.

Но, в принципе, можно и привязывать лайоуты и к конкретным единицам контента. Просто у меня такой нужды никогда небыло.

 

[player]

john.brown
Я думаю так и сделаю.
Да, у тебя немного подругому потомучто я поставил немного другие требования для цмс, и уже говорю про страницы изза того что концепция немного отличается. Но применять можно так же как и к модулям.
Спасибо!

 

[john.brown]

Блоки в шаблоне тупо прописываеться по месту, типа {$LEFT_TOP}, {$LEFT_MIDDLE}, но можно и задавать просто области, а в конфиге указывать позицию. Подход, имхо, гибок до безобразия

 

[Beavis]

просто для примера, в ZF подобная задача решается несколькими способами:
1. Если какой то неосновной блок должен быть на всех страницах (например меню), то можно добавить вызов этого экшена в ActionStack ещё до вызова диспетчера, и данный экшн будет всё время запускаться после основного, соотв-но в шаблоне всегда будет доступен этот блок
2. Если блок нужен только на некоторых страницах можно добавлять этот экшн в ActionStack непосредственно в основном экшене
3. Или можно прям из шаблона вызывать дополнительный экшн типа <?=$this->action("menu", "index")?>