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

[Sufir]

Только контроллер блока сам никуда не лезет, а ждет, пока его позовут.

Х.з., может мне по неопытности так кажется (около PHP я давно, но профессионально только шестой месяц), но в Zend Framework прекрасно реализованы такие "контроллеры". Только там они называются хелперами - очень удобно. Я не прав?

 

[Фанат]

Это, мне кажется, уже неважно.
Важно место, откуда эти хелперы вызываются.

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

И вот, если вернуться к теме Контроллера Шапки, мне нужно такое место, из которого можно дергать эти экшены для небольших блоков, плюс реализовать какую-никакую логику, определить несколько использующихся в шаблоне шапки переменных.

 

[С.]

Это не совсем то. Здесь не нужен МВЦ. Шапке не нужна модель. Шапке нужно только, чтобы в нужном порядке её контроллер обратился к нескольким сущностям и получил у них данные

Если данные присущи только данной шапке, то таки их должна добывать модель этого блока и МВЦ здесь кстати и оно даже не вырождено.

Ежели данные глобальные (ГЕТ, ПОСТ, поддомен), то для их подачи в шаблон никакой специальной сущности не надо. Подавай через модель или напрямую из контролера, как уж в вашем движке принято такие данные передавать в любые другие шаблоны, шапка здесь ничем не выделяется.

 

[fixxxer]

Шапке не нужна модель.

О!

Вообще не надо бить шаблон на шапки и футеры. Это какой-то phpnuke. Из шаблона должно быть видно всё, что касается отображения данной страницы, в любом месте.

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

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

 

[Фанат]

зачем-то возникает желание побить шаблон на части

Кость, извини, какую-то ерунду ты пишешь.
Шаблон на части побит по определению. Всегда. Вне зависимости от твоего или моего желания. Просто потому, что разные части шаблона несут разные функции, имеют разную область применения.

Как минимум, любой сайт можно разбить, условно говоря, на "рыбу" и "контент". "Рыба" - шаблон всего сайта, "контент" - шаблон конкретной страницы, вписываемый в "рыбу". Рыба по определению должна быть отделена от контента, потому что она используется на многих страницах сайта. Ну, если только мы хотим следовать принципу DRY, конечно, а не править, как наш друг Духовность, полсотни шаблонов, чтобы добавить один див в верстку.

 

[fixxxer]

Вот выцепил неудачную фразу и прицепился! =)

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

Касаемо порядка вывода. С наследованием все решается естественным образом - перебили блоки и всё. В случае с обычным php-шаблонами проблема в том, что на самом деле внутренность title тот же является блоком текущей страницы, а не общего лейаута; популярный паттерн с двухпроходными шаблонами в примитивной своей реализации имеет существенный недостаток в том, что он определяет один блок, а не любое их число. В xenforo, например, - а в нем как раз layout + page, - это решается возможностью в шаблоне страницы определить специальным тегом любые переменные, которые потом используются в шаблоне лейаута. Можно еще кучу вариантов придумать. Проблема, из-за которой возникли идеи про супервизоры, мне тут видится исключительно синтаксической - сложно придумать удобное синтаксическое пространство для такой вещи в рамках pure php templates.

 

[С.]

Я уже добрый десяток лет использую одну и ту же методику и еще ни разу она меня не подвела. Все делается одним проходом на нативном синтаксисе без оверинжиниринга. При чем я знаю, в чем ограниченность такого метода, но не разу оно еще не понадобилось.Сам факт, что это веб-приложение, а не сферический конь позволяет упростить многие вещи.

 

[Фанат]

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

 

[Ragazzo]

Фанат
Дак ты все таки пришел уже к какому-либо варианту конечному или просто иногда топик апаешь?

 

[С.]

От кого уж, но от тебя не ожидал такого аргумента. Мужики-то не знают... Типа можно создать такой инструмент, которой без дисциплины и контроля качества будет давать сам на гора идеальный МВЦ код. Да если какому придурку в голову взбредет, он данные в таком месте получит, что у тебя глаза на лоб вылезут, и никакие синтаксические ограничения не помогут их в глазницах удержать.

 

[Фанат]

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

 

[С.]

Тут вступает в игру принцип удобства. Если мне надо зарегестрировать модели, аргументы и еще хрен знает что в хреновой туче мест (к чему ты и клонишь), то даже я, человек в общем дисциплинированный, возможно пойду на хак. А если можно обойтись без этого головняка, очевидно и просто, то и хакать нет смысла.

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