Ах вон оно что :-) Значит мы просто не поняли фишку, да и не стремились особо, в те времена когда мы начали его использовать, у нас уже были готовые датасеты на всю страницу, поэтому мы решили обойтись без этого. Спасибо за то, что объяснили
Это же пример. И да, не отменяющий факта, что к сожалению, особых вариантов переиспользования под-шаблона в разных местах кроме include нет.
активно агитируют других
Я как раз не агитирую, всего лишь отвечаю на возникающие вопросы. Хотя с моей точки зрения, в случае, если есть доступ к установке расширений и не требуется тянуть фреймворки или другие шаблонизаторы для каких-то небольших проектов – Blitz неплох.
Под небольшими проектами я имею ввиду, к примеру, некую админку с десятком странчек, ради которой не то, что Laravel поднимать смыса нет, а любой шаблонизатор Blade/Twig/etc на php будет с кодовой базой в 10 раз большей самого этого проекта. Я его юзаю даже для одностраничек типа https://nickyx3.ru/geo/, благо на сервере оно и так есть
Всмысле пакетом? Это расширение на Си для PHP. Не, ну если совсем сильно хочется, то есть deb который мы собираем для себя, а так github его есть в первом абзаце статьи
то имеет смысл попробовать Twig, в котором изначально отсутствуют все те проблемы Blade
Twig отличается от Blade по сути только тем, что «компилированный» шаблон будет php-классом, а не куском php-спагетти кода. А синтаксис еще менее напоминающий синтаксис php (например циклов) - это для типичного верстальщика еще больший разрыв мозга. ИМХО
Да конечно работают, но вопрос то как раз и стоял «нафига нам php-код в шаблоне». У меня больше верстальщику делать нечего чтоли, только и мечтает php-код в шаблонах писать, да еще с непотребствами вот этих по-моему мнению совершенно плохо читаемых конструкций $a?$b:$c, $a?:$b, $a??$b . А уж гасить ошибки это вообще зло
Конечно с одной строны всякие условия в шаблонах это вроде тоже код, но это директивы шаблонизатора, которые во-первых ему понятнее, во-вторых единообразны и читабельны
Что непонятного в примере? Кроме того, что я для наглядности повторил блоки? Вы настолько плотно работали в Blitz чтоб понимать его проблемы? Мы его юзали около 10 лет (и продолжаем местами), мы знаем как его готовить и он прекрасен. И простейшая, не перегруженная логика там есть. Про отсутствие логики это вам надо смотреть в Mustache – почти индустриальный стандарт logic less templates.
Не надо ничего никуда, ни в каком "коде контроллера" смотреть.
Возьмем для примера некие данные, откуда угодно полученные, это не код "контроллера", это иллюстрация стуктуры.
Вы не поверите, ни разу не использовали в blitz ничего кроме load/parse. Система назначения блоков наверное кому-то нужна (в основном тем, кто хочет выдернуть кусочек шаблона с блоком через fetch), но совсем не обязательна. Собственно в моей обертке она и не используется.
Вообще забавно.
А код вида
use Illuminate\Support\Facades\View;
return View::make('greeting', ['name' => 'James']);
// или
return view('greeting', ['name' => 'James'])->render();
Чем отличается от
$template = new \Blitz('greeting.tpl');
return $template->parse(['name' => 'James']);
Тем более всё это в нашем случае скрыто за фасадом аналогично Blade
use NickyX3\Blitz\Facade\BlitzView;
return BlitzView::apply('greeting',['name' => 'James']);
Вот щас не понял, вы считаете, что содержимое папки Illuminate\View\* это не дополнительный код для обслуживания "шаблона Blade"?
Раз уж мы решили отойти от темы и обсудить шаблонизаторы. Для «обслуживания» шаблонов Blitz вообще не нужен PHP-код. Ибо сам шаблонизатор это extension. Но к теме это не относится :-)
Объясню мысль. Я прекрасно понимаю как работают оба шаблонизатора. И да, Blade ЗАСТАВИТ вас пихать в шаблон все данные которые в нем как-бы нужны (либо проверять в самом шаблоне их наличие). Вот только вам они могут быть не нужны в принципе. Ну например пусть у вас есть некая сущность, в которой могут быть какие-то атрибуты, а могут не быть (они в принципе могут быть подтянуты из какого-либо внешнего API например, где вы наличие данных контролировать не можете). Я же не хочу тащить в шаблон «лишние» данные несуществующих атрибутов, это и расход памяти, и некоторое раздувание кода – с моей точки зрения.
Реальный мир часто не совпадает с рендером только четко определенных моделей Eloquent с определенными атрибутами.
P.S> Вот так вот пишешь вроде статью про одно, а скатывается все в обсуждение какой шаблонизатор лучше. Никакой. У каждого свои преимущества и недостатки. Статья про то, что если вы знаете и используете что-то альтернативное типа Bllitz (на котором кстати и Хабр когда-то работал (а может и сейчас?), то есть способ прикручивания к Laravel.
А ещё мне кажется, что Blade, как standalone шаблонизатор с ходу использовать не получится, да ведь?
Да, наверняка это сработает, пока у вас в данных есть $var. А как не будет, ой. ошибка. Более того, я вижу тут php код в шаблоне. А не только директивы шаблонизатора.
Ах да, в случае Blade это генерация кода в скомпилированном шаблоне, в лучае Blitz никакой «компиляции» там нет
Ах вон оно что :-) Значит мы просто не поняли фишку, да и не стремились особо, в те времена когда мы начали его использовать, у нас уже были готовые датасеты на всю страницу, поэтому мы решили обойтись без этого.
Спасибо за то, что объяснили
Это же пример. И да, не отменяющий факта, что к сожалению, особых вариантов переиспользования под-шаблона в разных местах кроме include нет.
Я как раз не агитирую, всего лишь отвечаю на возникающие вопросы. Хотя с моей точки зрения, в случае, если есть доступ к установке расширений и не требуется тянуть фреймворки или другие шаблонизаторы для каких-то небольших проектов – Blitz неплох.
Под небольшими проектами я имею ввиду, к примеру, некую админку с десятком странчек, ради которой не то, что Laravel поднимать смыса нет, а любой шаблонизатор Blade/Twig/etc на php будет с кодовой базой в 10 раз большей самого этого проекта. Я его юзаю даже для одностраничек типа https://nickyx3.ru/geo/, благо на сервере оно и так есть
Как знакомый с Blitz отвечу, в таком примере так и будет, если «флаг» не сравнивать со значением, то он как в любом php коде будет приведен к bool.
Всмысле пакетом? Это расширение на Си для PHP. Не, ну если совсем сильно хочется, то есть deb который мы собираем для себя, а так github его есть в первом абзаце статьи
Twig отличается от Blade по сути только тем, что «компилированный» шаблон будет php-классом, а не куском php-спагетти кода. А синтаксис еще менее напоминающий синтаксис php (например циклов) - это для типичного верстальщика еще больший разрыв мозга. ИМХО
Конечно нет, я не стремился полностью повторить функционал фасада View
Да конечно работают, но вопрос то как раз и стоял «нафига нам php-код в шаблоне». У меня больше верстальщику делать нечего чтоли, только и мечтает php-код в шаблонах писать, да еще с непотребствами вот этих по-моему мнению совершенно плохо читаемых конструкций
$a?$b:$c
,$a?:$b
,$a??$b
. А уж гасить ошибки это вообще злоКонечно с одной строны всякие условия в шаблонах это вроде тоже код, но это директивы шаблонизатора, которые во-первых ему понятнее, во-вторых единообразны и читабельны
Что непонятного в примере? Кроме того, что я для наглядности повторил блоки? Вы настолько плотно работали в Blitz чтоб понимать его проблемы? Мы его юзали около 10 лет (и продолжаем местами), мы знаем как его готовить и он прекрасен. И простейшая, не перегруженная логика там есть. Про отсутствие логики это вам надо смотреть в Mustache – почти индустриальный стандарт logic less templates.
Не надо ничего никуда, ни в каком "коде контроллера" смотреть.
Возьмем для примера некие данные, откуда угодно полученные, это не код "контроллера", это иллюстрация стуктуры.
Попрбуем отрендирить его условно Blade
Чтоб не повторять код, можно даже внедрить дочерний подшаблон
Ну конечно вызовем
Теперь сделаем тоже самое на Blitz
Вызовем, пусть нативно даже
Много разницы? Мне кажется никакой. Что тут может быть непонятного?
Да неважно, возьмите тупой пример
{{ $some_flag ? $one : $two }}
Если $some_flag не определена, будет ошибка
А где вы увидели в блице php-код? Как раз таки только логика отображения, и никакого php-кода. И два раза как раз ничего писать не надо
Вы не поверите, ни разу не использовали в blitz ничего кроме load/parse. Система назначения блоков наверное кому-то нужна (в основном тем, кто хочет выдернуть кусочек шаблона с блоком через fetch), но совсем не обязательна. Собственно в моей обертке она и не используется.
Вообще забавно.
А код вида
Чем отличается от
Тем более всё это в нашем случае скрыто за фасадом аналогично Blade
Вот щас не понял, вы считаете, что содержимое папки Illuminate\View\* это не дополнительный код для обслуживания "шаблона Blade"?
Раз уж мы решили отойти от темы и обсудить шаблонизаторы. Для «обслуживания» шаблонов Blitz вообще не нужен PHP-код. Ибо сам шаблонизатор это extension. Но к теме это не относится :-)
{{ ($var ? $var : $var2) }}
? И что поменяется? Undefined variable $var как было так и останетсяТак это как раз не сложно, читаете что-то типа "Making Laravel Package", реализуете
Объясню мысль. Я прекрасно понимаю как работают оба шаблонизатора. И да, Blade ЗАСТАВИТ вас пихать в шаблон все данные которые в нем как-бы нужны (либо проверять в самом шаблоне их наличие). Вот только вам они могут быть не нужны в принципе. Ну например пусть у вас есть некая сущность, в которой могут быть какие-то атрибуты, а могут не быть (они в принципе могут быть подтянуты из какого-либо внешнего API например, где вы наличие данных контролировать не можете). Я же не хочу тащить в шаблон «лишние» данные несуществующих атрибутов, это и расход памяти, и некоторое раздувание кода – с моей точки зрения.
Реальный мир часто не совпадает с рендером только четко определенных моделей Eloquent с определенными атрибутами.
P.S> Вот так вот пишешь вроде статью про одно, а скатывается все в обсуждение какой шаблонизатор лучше. Никакой. У каждого свои преимущества и недостатки. Статья про то, что если вы знаете и используете что-то альтернативное типа Bllitz (на котором кстати и Хабр когда-то работал (а может и сейчас?), то есть способ прикручивания к Laravel.
А ещё мне кажется, что Blade, как standalone шаблонизатор с ходу использовать не получится, да ведь?
Да, наверняка это сработает, пока у вас в данных есть $var. А как не будет, ой. ошибка. Более того, я вижу тут php код в шаблоне. А не только директивы шаблонизатора.
Вкорячить можно что угодно. Если вы про серверный рендеринг XML/XSLT то он конечно есть https://www.php.net/manual/ru/book.xsl.php
Какую конкретно логику? По мне так в Blade/Twig этой самой логики в 10 раз больше.
В комментариях ниже есть немного рассуждений по этому поводу.
В Blade мне лично не достает однострочников типа
{{ if($var,$var,$var2) }}
или{{ $var }}{{ if($_last,'',', ') }}
в циклах