Шаблоны: супервизор

[Фанат]

не понял, при чем здесь include('header.php')
и при чем здесь <!-- start here -->

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

Мы говорим в этой ветке о контроллере для шаблона header.php ;-)
Я, собственно, всю эту тему начал именно из-за контроллера для header.php.
Исходя из того соображения, что ему тоже нужен контроллер.
Я совсем не спорю про написание пустых файлов - я точно так же делаю. Я вообще не об этом.
Тема для шаблона контента страницы - понятна и неинтересна. Я ее здесь не рассматриваю.
Сначала все идет как у тебя - фронт дергает контроллер страницы, тот готовит данные для шаблона, и в самую последнюю очередь дергает шапку... и тут выясняется, что в шапке надо вывести приветствие авторизованному пользователю, сформировать меню, показать баннеры и сайдбар. И получается, что надо дергать из шаблона некую бизнес-логику. Этим и занимается активный шаблон.

А в случае с пассивным главным шаблоном фронт-контроллер в самый последний момент дергает моего супервизора(!) который дергает бизнес-логику всех блоков головного шаблона, и только после этого запускает его рендеринг

 

[Фанат]

Собственно, именно об этом говорит Фабьен своим знаменитым " Сегодня на любом проекте вы верстаете сверху вниз, но выводите контент снизу вверх". То есть, для низа у вас уже готов вывод (для блока контента), а для верха - шапки - все только еще начинается.
Но его заявление о том, что на чистом пыхе это невозможно - дурость. И мой супервизор - ответ Фабьену.

 

[флоппик]

А в случае с пассивным главным шаблоном фронт-контроллер в самый последний момент дергает моего супервизора(!) который дергает бизнес-логику всех блоков головного шаблона, и только после этого запускает его рендеринг

Я уже пытался тебе рассказать про методы before() и after() в которых такое и происходит обычно.

 

[С.]

Действительно со словами надо поаккуратнее. Потому что после фразы

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

хочется четвертовать того, кто таким образом нарушает MVC. Но на самом деле все совсем не так. Шаблон не дергает никай бизнес логики. Он просто декларирует: "Кстати здесь будет блок приветствие пользователю". Контроллер это видит и сам дергает бизинес логику, находит, какой шаблон сюда поставить и т.д. Все вполне законно и канонично. По сути активный шаблон даже твоего супервизора явно не дергает, он просто обозначет место вставки блока, что так или иначе все равно придется сделать. И самое приятное, что все это достигается одним проходом.

 

[Фанат]

флоппик
Метод это не может быть метод, это должен быть класс.
Поскольку в нем, во-первых, будет куча своих методов - на каждый виджет, а, во-вторых - много инстансов, по одному на каждый главный шаблон.

 

[Фанат]

И самое приятное, что все это достигается одним проходом.

Ты гонишь. Одним проходом это не достигается вообще. Я, во всяком случае, не представляю, как ты собираешься это делать в один проход.
Вот двухпроходный - да, не грешит против MVC, да. Но все равно - он связывает руки разработчику, ограничивая логику вызова виджетов тупой декларацией "здесь будет блок".
Но логика эта не всегда настолько прямолинейна, блоки могут влиять друг на друга.

Именно поэтому я предлагаю для такой не самой примитивной сущности, как главный шаблон сайта, иметь свой контроллер. Это, на самом деле, очень логично. Ведь то же самое, что ты написал про него, можно написать и про контроллер страницы:

По сути активный шаблон просто обозначет место вставки переменной.

Ну да, а переменные поставляет модель. Значит, контроллер получается вовсе не нужен

 

[С.]

Ты гонишь. Одним проходом это не достигается вообще. Я, во всяком случае, не представляю, как ты собираешься это делать в один проход.

Наверное ключ в словах "Я, во всяком случае, не представляю...". Я тут не один такой "гонщик", которые пытаемся тебе донести, что это работает.

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

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

Значит, контроллер получается вовсе не нужен

Бинго! Только не нужен здесь т.н. контролер блока/страницы, о чем я тоже говорил ранее. Единый контролер системы (фронт-контролер, диспетчер и т.п.) тем не менее остается.

 

[Фанат]

Возможно, мы опять говорим о разном.
вот пример главного шаблона

<body>
<title><?=$title?></title>
<? call('login_form') ?>
<div style ="main">
<? include $page_tpl ?>
</div>

каким образом при однопроходности будет обеспечено выполнение модуля login_form до начала вывода?

 

[С.]

Я понимаю к чему ты ведешь, но пример не самый удачный. Во-первых отрисовка, самой формы не обязана быть в начале. Во-вторых, пароль проходит ПОСТом, а после ПОСТа мы ведь редиректим, правда? А если даже не редиректим, то экшн формы нас куда направляет? Всяко не на модель блока 'login_form', а на ту, результат которой потом окажется в $page_tpl, то есть и так выполнится ранее, до вызова блока 'login_form'. То есть бизнес логика авторизации не может находится в модели блока 'login_form' независмо от активности/пассивности/проходности шаблона, просто потому что oбратившись к вебстранице, мы не можем назначить обработчиком какой-то ее внутренний подблок.

UPD: Хотя технически мы можем назначить в экшн формы 'login_form'. Тогда этот блок будет обработан дважды: сначала в теле страницы, потом в шапке. Если дизайн сайта позволяет, то никаких проблем.

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

 

[Absinthe]

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

Страницы или любой сущности (вид, миграция, модель и т.д.)?

 

[Фанат]

Я понимаю к чему ты ведешь

Нет, не понимаешь. Я вообще никуда не "веду". Я пишу открытым текстом.
Мы говорим об отрисовке форм, а не их обработке.

Я уже объяснял выше, но повторю сейчас.
Блок login_form - общий для всего сайта. Это элемент Главного шаблона. К контроллеру конкретной страницы он отношения не имеет.
При этом у него есть свой контроллер - экшен из модуля юзерс. и свой маленький шаблон. Это такая мини-страница.
Чтобы заполнить шаблон, нужно обратиться к модулю юзерс, который вернет либо данные для формирования ссылок на личный кабинет, либо ничего не вернет и надо будет рисовать форму.

Весь вопрос в том - кто и когда будет делать это обращение к модулю юзерс.

Покажи мне алгоритм однопроходного шаблона, при котором обращение к users->login_form будет сделано до начала отрисовки шаблона.

 

[С.]

А, ну тогда все еще проще. Этот блок будет отрисован тогда, когда встретится. В данном примере -- в конце. Он совершенно не обязан быть отрисован в начале, потому что

Это элемент Главного шаблона. К контроллеру конкретной страницы он отношения не имеет. ... При этом у него есть свой контроллер - экшен из модуля юзерс. и свой маленький шаблон. Это такая мини-страница.

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

P.S. Если ты не хотел меня поймать на авторизации, мог бы блок "news" в шапку вставить.

 

[С.]

Страницы или любой сущности (вид, миграция, модель и т.д.)?

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

function ...()
{
}

Но фреймворк, который не может от меня скрыть какие-то повторяющися из файла к файлу символы, идет в жопу.

 

[Absinthe]

С. ты путаешь понятия "есть функция генерации" и "необходима функция генерации".
Мне вот гораздо удобнее ими пользоваться, так быстрее.

 

[С.]

Я не путаю. Я считаю, что надо открыть пустой файл и начать писать в нем бизнес код прямо с первой строчки. Что там такое необходимое можно нагенерить?

 

[Фанат]

на каком основании и с какой целью ты требуешь его отрисовки до начала вывода?

Не отрисовки. А выполнения контроллера.
Ты мой пример смотрел?
В нем начинается вывод. Потом шаблонизатор встречает декларацию: "Кстати здесь будет блок приветствие пользователю". Контроллер это видит и сам дергает бизинес логику.
В итоге получается, что вывод начался раньше, чем отработала бизнес-логика этого блока.

 

[Absinthe]

Я не путаю. Я считаю, что надо открыть пустой файл и начать писать в нем бизнес код прямо с первой строчки. Что там такое необходимое можно нагенерить?

Ты уже 2 раза пишешь: название файла и название класса.
С генератором же надо сделать это лишь раз. Если указан список экшенов, то генератор создаст пустые методы в классе и пустые вьюхи к каждому.

В итоге с генератором все быстрее, а не медленнее, как ты говоришь.

 

[С.]

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

Варианты прочтения твоей фразы:

1. В итоге получается, что вывод <шаблона блока> начался раньше, чем отработала бизнес-логика этого блока.
Ответ: Нет, он начался после.

2. В итоге получается, что вывод <HTML кода перед блоком> начался раньше, чем отработала бизнес-логика этого блока.
Ответ: Ну и что? Что от этого изменилось?

 

[Фанат]

Ну и что? Что от этого изменилось?

Всё.
Вывод начался раньше, чем отработала бизнес-логика.
Со всеми вытекающими последствиями.

похоже, я просто зря трачу время. Хочется конструктивного диалога, а не пережёвывать очевидные вещи

 

[С.]

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

Это я написал несколькими постами раньше, но ты продолжил, чтобы услышать эти еще раз, но уже расстроиться. У тебя есть какой-то очевидный тебе запрет на это, а у других его нет, тем более, что никакого архитектурного криминала в этом не наблюдается. Мы точно также обращаемся между слоем бизнес логики и слоем хранилища, не смешивая их. Почему этот же принцип нельзя применить между отображением и бизнес логикой? Тем более, что на практике это зарабатало просто превосходно. Только предубеждения могут помешать.

P.S. Если ты про <title>, то я тебе скажу одну вещь: никогда какой-то внутренний рядовой блок из шапке не будет решать, что написать в <title>. Экшн-блок из тела страницы - да, пожалуйста. Чтобы не остаться навечно в поисках идеала, надо провести черту, где кончаются реальные задачи и начинаются только умозрительные.