Smarty & загрузка и старт PHP контроллера

[keltanas]

Absinthe, ESI, я говорю про ESI

 

[fixxxer]

А сколько их передавать из контроллера допустимо?
В моем примере мы обращаемся к модели из вида. Это нормально. Этим данным в контроллере делать нечего.
Как ты предлагаешь их получать в виде? Виджет делать?

Мне, если честно, ни то, ни другое не нравится.

Вот только что подумал - а если так?

return new View('file.tpl', [
    'newsCollection' => function() { return NewsCollection::all(); }
   // ...
]);
...
{% if weWannaSeeNews %}
   {% for newsItem in newsCollection %}
   ...
   {% endfor %}
{% endif %}

Подразумевается, каэш, что мы научили template engine дергать value closures.

 

[AmdY]

AmdY, ок
1. Читабельность и наглядность ни сколько не хуже, если не лучше
2. Нужны лишние действия для создания скоупа - то же, что и создание контроллера. Блок можно тянуть из соседнего экшена того же контроллера, который создал и саму страницу
3. ESI по умолчанию подразумевает удобное кеширование блоков
4. Для каждого блока отдельный шаблон без лишнего кода, полный reusable любого блока - куда удобнее?
5. Сущности и знания те же самые, только вместо разбивки на блоки получаем лапшу. В ESI никакой зависимости между блоками.
6. Аналогично.
7. Блоки можно тестировать отдельно от остальной страницы, при чем в том числе в зависимости от прав пользователей
8. Инвалидация кеша хоть по времени жизни, хоть по хешу контента
9. При необходимости, блок можно подтянуть аяксом

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

 

[keltanas]

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

 

[Вурдалак]

AmdY, а как ты выводишь блоки, которые не имеют никакого отношения к данному контроллеру?

Я делаю запрос «/user/42.json» — получаю юзера.
Я делаю запрос «/user/42.html» — получаю юзера и ещё всякую хрень типа последних новостей на сайте. News::lastNews()?

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

 

[Absinthe]

AmdY, а как ты выводишь блоки, которые не имеют никакого отношения к данному контроллеру?

Я делаю запрос «/user/42.json» — получаю юзера.
Я делаю запрос «/user/42.html» — получаю юзера и ещё всякую хрень типа последних новостей на сайте. News::lastNews()?

Как раз идеально ложится на шаблон такой вызов модели. И в json как раз этих данных не будет.
Прекрасный пример в поддержку этого способа

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

В модели.

 

[AmdY]

keltanas, бля, ну ESI это лигшь красивое название для таких же хаков. Просто обозвали красивым словом, так же как HMVC и является продолжением SSI. Вот код по твоей ссылке

<?php echo $view['actions']->render(
    new \Symfony\Component\HttpKernel\Controller\ControllerReference('...:news', array('max' => 5)),
    array('strategy' => 'esi'))
?>

<?php echo $view['actions']->render(
    $view['router']->generate('latest_news', array('max' => 5), true),
    array('strategy' => 'esi'),
) ?>

 

[AmdY]

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

 

[keltanas]

AmdY, ну и что. Зато код все равно получается чище и управляемее, чем дерганье модели из шаблона.
И кстати так лучше
{{ render_esi(controller('...:news', { 'max': 5 })) }}

 

[ggfdsfds]

В общем прихожу к выводу что это допустипо - в шаблоне в отдельных местах делать "дергание данных". Но без использования логики - когда дергаешь модель - т.е. не нужно передавать там кучу параметров 5, здесь 10 и т.д. А то это уже получается в шаблон вписываеш то, по идее за что должен отвечать контроллер или модель. Просто название класса - и вызов функции.

Но в любом случае должен быть MVC - и тогда все будет более правильно и аккуратно.

 

[Absinthe]

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

Через дополнительный костыль чище, чем напрямую?
Вид может получать данные из модели, никакого нарушения MVC тут нет. Почему тебе кажется, что этот код грязный?

 

[ggfdsfds]

Через дополнительный костыль чище, чем напрямую?
Вид может получать данные из модели, никакого нарушения MVC тут нет. Почему тебе кажется, что этот код грязный?

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

Для банальных header , footer - или главной - где необходимо получить - например список последних новостей - это еще куда не шло. Но все равно - мне кажется, что лучше все это загружать в модель.
В общем думаю, что оставлю и то (сама логика старта Smarty объекта) и то (плагин {dataGet model="className" func="main"}.

 

[Absinthe]

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

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

 

[ggfdsfds]

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

Для банальных header , footer - или главной - где необходимо получить - например список последних новостей - это еще куда не шло. Но все равно - мне кажется, что лучше все это загружать в модель.
В общем думаю, что оставлю и то (сама логика старта Smarty объекта) и то (плагин {dataGet model="className" func="main"}.

Хотя что интересно - вот первый сайт - который сделан на вот таких {dataGet} - мне понравился с точки зрения логики меньше (их просто куча в шаблоне), чем тот сайт, где все крутится вокруг контроллера.

 

[ggfdsfds]

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

Имею в виду вот так:



Когда еще в вот эти параметры запихивают {assign} чего-то там и особенно из GET-запросов.

 

[Absinthe]

Вот так - нет. А вызвать статик метод модели - да.
Хотя в энтерпрайз-коде тоже нет. Но в нем и ActiveRecord тоже не будет.

 

[ggfdsfds]

Ясно, спасибо.

 

[Вурдалак]

Прекрасный пример в поддержку этого способа

Я как бэ про это:

А вызвать статик метод модели - да.

Полное днище. А не про 100500 переменных в return View().

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

Но мне ESI не очень нравится идеологически.

 

[Вурдалак]

Через дополнительный костыль чище, чем напрямую?
Вид может получать данные из модели, никакого нарушения MVC тут нет. Почему тебе кажется, что этот код грязный?

Получать, конечно, может. Но не из воздуха.

 

[Absinthe]

Вурдалак, есть разные походы. Тот подход, который я описал, является хорошим тонов в фреймворках типа Rails. К примеру, в Laravel.

во всяком случае не далеко от него по трудоёмкости (функцию для Twig, кеширование, etc.).

И именно поэтому в нем не Twig, а Blade.