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

[Ragazzo]

lagoff
болтовня ничего не стоит, покажите нам код.

 

[lagoff]

Ragazzo, вам код чего конкретно показать? Укажите моменты, которые неясны, я проиллюстрирую из кодом.

 

[Ragazzo]

lagoff
Того что вы описали, фраза

Принцип такой же как в HMVC. Т.е. по сути тот же модуль, только диспетчеризация внешних запросов запрещена.

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

 

[Фанат]

lagoff
"Учить" тоже надо было взять в кавычки.
потому что никакой полезной информации в ответе не содержится, а недовольно поучать мы и сами прекрасно умеем, помощь не требуется.

лучше внедрить некую концептуальную сущность под названием "виджет"

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

Где и как его вызвать - дело второе.

К сожалению, вопрос был именно в этом.

 

[lagoff]

HMVC в том то и заключается его прелесть что это форвардинг именно запросов

Прелесть HMVC далеко не форвардинге запросов, а сути самого HMVC. Форвардинг это просто просто технология, не более.

диспетчеризация внешних запросов запрещена. Разрешены только внутренние, т.е. напрямую из кода

Читайте внимательнее, прежде чем вешать ярлыки.

Так что вы по сути приравняли виджет(что вы там понимаете) к системе форвардинга запросов и многослойной архитектуре

Неет, сущность и технология вещи абсолютно разные.

В общем, насколько я понимаю, либо я криво объяснил концепт решения, либо вы недопоняли. Ладно суть не в этом, я не гордый. Попробуем еще разок.

Вот что мы имеем изначально.

Меню, обычно - это не совсем простой код, и по-хорошему, оно бы должно быть оформлено отдельный блок в шаблоне... со своим собственным контроллером(?), который получает данные для построения меню.
Вопросы:
Где этот контроллер должен быть расположен?
Откуда вызываться?

Нормализуем вопросы, составим их более абстрактно:
1) Кому отдать ответственность за генерацию некого сквозного UI блока, например меню (тут я подразумеваю конечный результат генерации в принципе - html, а не просто какие-то данные).
2) Кто будет вызвать того, кто эту ответственность получит.

Теперь ответы:
1.1) Если мы используем HMVC, то создать для этого UI блока отдельный контроллер, например:
..../modules/widgets/controllers/menu.php
C экшеном show внутри. В котором реализуем выборку данных и генерацию html'a

1.2) Если мы не используем HMVC - некий класс, назовем его условно UIComponent_Menu, в который инкапсулируем получение данных и генерацию html'a.

2) И то и другое можно вызвать откуда угодно:

1) из кода экшена контроллера какой-либо страницы
2) из кода самого контроллера (если есть возможность)
3) из кода класса модуля (если модульность есть в проекте/фреймворке)
3) из кода класса приложения (если есть такой в проекте)
4) напрямую из шаблона через ViewHelper, например, ViewHelperUIComponent::show(<component_name>, <args>);

 

[Ragazzo]

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

 

[Фанат]

Между пунктами 1-4 не вижу большой разницы.
Все они неприемлемы, поскольку модулей, контроллеров и классов в приложении десятки и сотни, и в каждом писать вызов меню - это либо просто глупо, либо ещё и во вред:
Скажем, какой-то из экшенов возвращает не хтмл страницу, а джейсон. И нафига контроллеру при этом рендерить меню - загадка. С какой стати вообще модуль user, к примеру, должен заниматься меню?

напрямую из шаблона

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

 

[lagoff]

Между пунктами 1-4 не вижу большой разницы.

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

Скажем, какой-то из экшенов возвращает не хтмл страницу, а джейсон. И нафига контроллеру при этом рендерить меню - загадка.

Что хочет получить клиент в качестве ответа, UI (я подразумеваю html) или сырые данные в каком-либо формате, например JSON, должно быть известно заранее. Поэтому организовать "вилку", чтобы предотвратить лишние вычисления не представляет труда.

С какой стати вообще модуль user

С чего вы взяли, что он должен это делать? Зачем? Это компонент, который находится в лэйауте, который (лэйаут) предположительно общий для всего сайта/приложения. Значит и вычислять его надо где-то на этом уровне, а не в каком-то там модуле. Модуль и без меню проживет.

вы открыли нам глаза на активные шаблоны,

не владею вашей терминологией. Прочитал две страницы назад , но так и не понял, что точно вы подразумевате под этим понятием.

Дергать хелпер в шаблоне - это абсолютно нормально. Ничего плохого не вижу. Вот организовывать вычисления в шаблоне или впихивать логику/ветвление - вот это плохо.

Честно не понимаю, в чем у вас затык.

 

[lagoff]

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

Ragazzo, вы местный остряк/шутник? Не знаю за кого вы меня принимаете, но раньше меня тут не было.

 

[Фанат]

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

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

 

[Absinthe]

Решил наконец прочитать целиком.

Не понял это:

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

Они же вместе сосуществуют в удобном варианте! Из базового шаблона его и вызывают.

 

[Фанат]

Не понял это:

Не понял, кто вместе, но зато сформулировал свои претензии к перечисленным подходам:

1. Однопроходный активный шаблон. Вообще не вариант, поскольку вывод начинается раньше отработки бизнес-логики (в виджетах).
2. Двухпроходный активный шаблон. Самообман! Первый проход выполняет функции контроллера. Только не честно - напрямую, а зачем-то в виде "прохода" по шаблону, чудовищно урезая доступный функционал.
3. Наследование (когда шаблон конкретной страницы наследует). Это вообще не совсем в тему, поскольку касается только шаблона, но не контроллеров. Ну унаследовали мы кусок шаблона для отображения облака тегов от основного шаблона - а заполнять его чем? Где данные для него брать?

 

[ksnk]

4) Парсинг шаблона в результате которого у нас появляется список активных шаблонов(виджетов). (Разовая операция выполняемая по изменению пучка шаблонов). По списку виджетов строим php-код для его (списка) инициализации. Код нужен в случае, если нужно учесть особенности инициализации виджетов, описанных в шаблоне. Если особеностей нет код можно не строить.
Первый проход "двухпроходного" метода делал примерно то-же самое.

Тоесть фенечка - код инициализации активных шаблонов СТРОИТСЯ по шаблону. Желательно в момент трансляции шаблонов шаблонизатором, но это не всегда возможно-обязательно...

 

[С.]

Все-таки может кто-нибудь снизойдет, очень хочется понять, что такое "контроллер шаблона". У меня если в шаблоне стоит например <?=insert('news')?> или {INSERT news}, то этому соответствует два физических файла: news.biz.php и news.tpl.php. Сначала вызывается првый и готовит все данные (что я с чистой совестью отношу к бизнес логике), а потом вызывается и собственно шаблон. Где у меня здесь должен быть контроллер шаблона? Что я делаю не так, если я не могу найти места для него?

 

[Фанат]

4) Парсинг шаблона в результате которого у нас появляется список активных шаблонов(виджетов).

не понял, чем это отличается от (2)

 

[Фанат]

У меня если в шаблоне стоит например <?=insert('news')?> или {INSERT news},

Здесь описан активный шаблон, в его однопроходной (<?=insert('news')?>) или двухпроходной ({INSERT news}) реализации.
Их недостатки я описал выше.

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

Очень хороший вопрос, прямо в точку.
Для news.tpl.php контроллером является news.biz.php.
Но я в этом топике говорю о том, что все почему-то забывают, что шаблон, в котором

стоит например <?=insert('news')?> или {INSERT news}

тоже требует своего контроллера!
И эти вызовы должны делаться именно в нём.
А шаблон должен заниматься своими прямыми обязанностями - рендерить данные в HTML, а не заниматься организацией вызовов

 

[ksnk]

не понял, чем это отличается от (2)

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

 

[С.]

Для news.tpl.php контроллером является news.biz.php.

Тогда что-то опять не так у нас с терминологией. news.biz.php [у мнея] является моделью, в нем стот грубо говоря SELECT * from news.

Но я в этом топике говорю о том, что все почему-то забывают, что шаблон, в котором стоит например <?=insert('news')?> или {INSERT news} тоже требует своего контроллера!

Ну так <?=insert('news')?> находится в body.tpl.php, a ему соответсвует body.biz.php.

 

[Фанат]

Ну так <?=insert('news')?> находится в body.tpl.php, a ему соответсвует body.biz.php.

А чем занимается этот body.biz.php?

Тогда что-то опять не так у нас с терминологией. news.biz.php [у мнея] является моделью, в нем стот грубо говоря SELECT * from news.

Этого не может быть.
Модели недостаточно для получения данных - нужен контроллер, который будет посредником между НТТР запросом и моделью.

 

[Фанат]

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