Blitz

Shurik

Новичок
Доброго времени суток! Понадобился Blitz, но он крайне отличается от смарти, до сих пор не понимаю для чего он нужен...

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

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

немного подумал и))) и решил сделать по своему, но вопрос в том нормальная ли это конструкция для blitz
PHP:
class Template
{
    public $blitz;
    public $tpl_dir;
    public $assign = array();
    public $assign_global = array();

    public function __construct()
    {
        parent::__construct();
        if(empty($this->blitz))
        {
            $this->tpl_dir = '/templates/tpl/';
            $this->blitz = new Blitz();
        }
    }

    public function get_tpl($template)
    {
        $this->blitz->setGlobal($this->assign_global);
        return $this->blitz->include($this->tpl_dir . $template, $this->assign);
    }

    public function assign($var, $value)
    {
        $this->assign[$var] = $value;
    }

    public function assign_global($var, $value)
    {
        $this->assign_global[$var] = $value;
    }

    public function get_var($var = '')
    {
        return $this->assign;
    }
}
 
Последнее редактирование модератором:

fixxxer

К.О.
Партнер клуба
Я, конечно, сто лет им не пользовался, но.
Просто собирай всё в массив, забудь про block(), и делай $blitz->parse($data) (или display) один раз.
Контексты в массиве собираешь во вложенные массивы.
Так намного проще.
http://alexeyrybak.com/blitz/quick_geek.html вот тут есть такие примеры.
 

Shurik

Новичок
Я, конечно, сто лет им не пользовался, но.
Просто собирай всё в массив, забудь про block(), и делай $blitz->parse($data) (или display) один раз.
Контексты в массиве собираешь во вложенные массивы.
Так намного проще.
http://alexeyrybak.com/blitz/quick_geek.html вот тут есть такие примеры.
Именно в этом заключается идея - просто собрать все переменные, попутно подключить необходимые шаблоны и вывести все это в основном макете. Задача в том что бы разделить программную часть от верстки. Blitz так устроен что реализовать сложно. К примеру в отличии от смарти у верстальщика нет возможности вывести дерево категорий в рекурсивной функции, это надо делать со стороны php. Можно обойти посредством подключения php но {{ incluede(tree.php) }} мне просто выводит код файла. Так же нельзя закешировать подключаемые шаблоны. Выходит так что надо подключить пользовательские функции для таких задач. Но останется ли после всего этого смысл использовать blitz, будет ли он все так же шустро работать?

Blitz используется потому как предполагается высокая посещаемость... Возможно есть альтернативы? Для меня сейчас остается только вариант подключить пользовательские функции или отказаться от шаблонизатора вовсе потому как работа программиста и верстальщика при данной схеме не разделяется.
 
Последнее редактирование:

Вурдалак

Продвинутый новичок
Я бы советовал отказаться от Blitz, это ничего, кроме боли, не принесёт.
 
  • Like
Реакции: AmdY

fixxxer

К.О.
Партнер клуба
якобы blitz очень шустрый и совсем не нагружает систему.
Этот аргумент был актуален во времена PHP4, когда blitz и разрабатывался. Сейчас это не более, чем миф.

Во-первых, с тех времен php стал намного, очень намного быстрее. Особенно php7.

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

Без возможности вызова php-функций из шаблона не обойтись. Например, всегда будет функция вида {{ route('some.page') }}. В компилируемом движке типа Twig/Smarty/Blade это скомпилится в обычный php-код, который, в свою очередь, скомпилится в zend-опкоды, где будет прямой вызов функции/метода и все будет хорошо.

А вот в blitz будет, условно говоря, переключение из extension-а в zend vm и обратно. Это примерно то, что делает функция call_user_func_array, что несколько медленнее прямого вызова. А из extension-а это еще медленнее.
 

Shurik

Новичок
Всем спасибо за отклик, уже ставлю Smarty! Если у кого то еще будут технические аргументации буду благодарен, очень понадобится!
 

fixxxer

К.О.
Партнер клуба
Советую ставить Twig ;) С ним жизнь намного проще. На хабрастатьи со сравнением вида "что будет, если сделать цикл из миллиарда секций" внимание обращать не стоит.

Если вдруг приложение уткнется таки в шаблоны, а не в работу с базой и подобные вещи (в чем я очень-очень сомневаюсь), есть расширение для ускорения Твига https://github.com/fabpot/Twig/tree/master/ext/twig
 

Shurik

Новичок
Советую ставить Twig ;) С ним жизнь намного проще.
думал о нем, посмотрел https://habrahabr.ru/post/128083/ и как то передумал. Какие плюсы?

в смарти есть возможность сделать так
test.tpl:
{$category = $api->categories->get_category(1)}
{include file='test.tpl' cache_lifetime=500}

много "плюшек" которые позволяют гибко работать с макетом

могу ли я в twing повторить что то подобное? и как это будет выглядеть?
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
В твиге главная плюшка - невозможность получить fatal error. Если в Смарти передать массив, а в шаблоне написать {$foo->value} вместо {$foo['value']}, будет еррор. Твиг достаточно умный, чтобы разобраться, что к чему - всегда достаточно писать {{ foo.value }}. Это касается и всего остального - в твиге кодом шаблона практически невозможно получить php error (разве что свое расширение написать). Это, правда, и есть то самое медленное место (из-за которого вот такие вот смешные статьи на хабре с абсолютно искусственными бенчами). Решается это установкой того самого расширения, где эта функция со всей магией реализована на C. Твиг автоматически определяет наличие расширения и начинает его использовать.

Другая плюшка - наследование (extends/blocks/use), в Смарти очень ограниченная реализация.

Ну и архитектура. Достаточно заглянуть в код Твига и в код Смарти. Писать расширения для Твига на порядок приятнее.

{$category = $api->categories->get_category(1)}
Можно ({%set%}). Но вообще очень не советую так делать, этому не место в шаблоне.

Насчет кэша не уверен, но кэш с лайфтаймом без инвалидации - это вообще так себе идея. Часть страницы обновилась, часть нет. Если уж такое кэширование нужно для вот тех самых $api->categories->get_category(1) - лучше сделать это все в php-коде (если нужны хитрые условия, то твиг-расширением) и передавать в шаблон уже готовые данные. Там, хотя бы, есть полный контроль над инвалидацией.
 
Последнее редактирование:

Shurik

Новичок
В твиге главная плюшка - невозможность получить fatal error. Если в Смарти передать массив, а в шаблоне написать {$foo->value} вместо {$foo['value']}, будет еррор. Твиг достаточно умный, чтобы разобраться, что к чему - всегда достаточно писать {{ foo.value }}. Это касается и всего остального - в твиге кодом шаблона невозможно получить php error (разве что свое расширение написать). Это, правда, и есть то самое медленное место (из-за которого вот такие вот смешные статьи на хабре с абсолютно искусственными бенчами). Решается это установкой того самого расширения, где эта функция со всей магией реализована на C. Твиг автоматически определяет наличие расширения и начинает его использовать.

Другая плюшка - наследование (extends/blocks/use), в Смарти очень ограниченная реализация.

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

AnrDaemon

Продвинутый новичок
В твиге главная плюшка - невозможность получить fatal error.
Это вообще бред собачий. Не желаю, чтобы шаблонизатор за меня что-то додумывал.
Ну и потом у меня VO implements ArrayAccess, так что по любому в шаблоне будет {$foo.value}, ибо у меня тоже голова не моссовет, помнить, где что.
 

fixxxer

К.О.
Партнер клуба
А нафига фронтендеру вообще понимать, где там в PHP объекты, а где массивы (которые почему-то ведут себя частично как объекты в JS)?

У фронтендеров от этой всей PHP-шной специфики мозг взрывается. Твиг от этого избавляет.
 

Shurik

Новичок
Насчет кэша не уверен, но кэш с лайфтаймом без инвалидации - это вообще так себе идея. Часть страницы обновилась, часть нет. Если уж такое кэширование нужно для вот тех самых $api->categories->get_category(1) - лучше сделать это все в php-коде (если нужны хитрые условия, то твиг-расширением) и передавать в шаблон уже готовые данные. Там, хотя бы, есть полный контроль над инвалидацией.
смысл в том что бы дать верстальщику больше возможностей. к примеру есть меню категорий которые меняются редко, но даже если меняются можно очистить кеш определенных шаблонов, при этом не надо объявлять (если конечно в этой выборке нет потребности в других шаблонах) переменные в коде. Достали дерево категорий и больше к ним не обращаемся. опять же тем же кроном можно обновлять кеш что бы это не ложилось на пользователей.
 

fixxxer

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

Да и за получение данных тоже. Верстальщик легко устроит O(n^2) там, где можно обойтись O(n) или даже O(1).

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

AnrDaemon

Продвинутый новичок
А нафига фронтендеру вообще понимать, где там в PHP объекты, а где массивы (которые почему-то ведут себя частично как объекты в JS)?

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

fixxxer

К.О.
Партнер клуба
Твиг как раз и дает комфортные условия работы. В общем, понятно, тебе поспорить ради спора надо.
 
Сверху