Pull to refresh
3
0
NickyX3 @NickyX3

User

Send message

Ах да, в случае Blade это генерация кода в скомпилированном шаблоне, в лучае Blitz никакой «компиляции» там нет

Ах вон оно что :-) Значит мы просто не поняли фишку, да и не стремились особо, в те времена когда мы начали его использовать, у нас уже были готовые датасеты на всю страницу, поэтому мы решили обойтись без этого.
Спасибо за то, что объяснили

Зачем вы все время выносите кусок шаблона в отдельный файл? Причем одну строчку

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

активно агитируют других

Я как раз не агитирую, всего лишь отвечаю на возникающие вопросы. Хотя с моей точки зрения, в случае, если есть доступ к установке расширений и не требуется тянуть фреймворки или другие шаблонизаторы для каких-то небольших проектов – Blitz неплох.

Под небольшими проектами я имею ввиду, к примеру, некую админку с десятком странчек, ради которой не то, что Laravel поднимать смыса нет, а любой шаблонизатор Blade/Twig/etc на php будет с кодовой базой в 10 раз большей самого этого проекта. Я его юзаю даже для одностраничек типа https://nickyx3.ru/geo/, благо на сервере оно и так есть

 но мне кажется, в случае $var === 0, в коде выше выведется $var2

Как знакомый с Blitz отвечу, в таком примере так и будет, если «флаг» не сравнивать со значением, то он как в любом php коде будет приведен к bool.

Всмысле пакетом? Это расширение на Си для PHP. Не, ну если совсем сильно хочется, то есть deb который мы собираем для себя, а так github его есть в первом абзаце статьи

то имеет смысл попробовать Twig, в котором изначально отсутствуют все те проблемы Blade

Twig отличается от Blade по сути только тем, что «компилированный» шаблон будет php-классом, а не куском php-спагетти кода. А синтаксис еще менее напоминающий синтаксис php (например циклов) - это для типичного верстальщика еще больший разрыв мозга. ИМХО

Конечно нет, я не стремился полностью повторить функционал фасада View

Да конечно работают, но вопрос то как раз и стоял «нафига нам php-код в шаблоне». У меня больше верстальщику делать нечего чтоли, только и мечтает php-код в шаблонах писать, да еще с непотребствами вот этих по-моему мнению совершенно плохо читаемых конструкций $a?$b:$c$a?:$b$a??$b . А уж гасить ошибки это вообще зло

Конечно с одной строны всякие условия в шаблонах это вроде тоже код, но это директивы шаблонизатора, которые во-первых ему понятнее, во-вторых единообразны и читабельны

Что непонятного в примере? Кроме того, что я для наглядности повторил блоки? Вы настолько плотно работали в Blitz чтоб понимать его проблемы? Мы его юзали около 10 лет (и продолжаем местами), мы знаем как его готовить и он прекрасен. И простейшая, не перегруженная логика там есть. Про отсутствие логики это вам надо смотреть в Mustache – почти индустриальный стандарт logic less templates.

Не надо ничего никуда, ни в каком "коде контроллера" смотреть.

Возьмем для примера некие данные, откуда угодно полученные, это не код "контроллера", это иллюстрация стуктуры.

$data = [
  'item' => ['name'=>'Vasya'],
  'items' => [
    ['name'=>'Petya'],
    ['name'=>'FanatPHP'],
  ],
];

Попрбуем отрендирить его условно Blade

@isset($item)
<div class="item">{{ $item['name'] }}</div>
@endisset
@forelse ($items as $item)
    <div class="item">{{ $item['name'] }}</div>
@empty
    <p>No items</p>
@endforelse

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

<!-- item -->
<div class="item">{{ $item['name'] }}</div>
<!-- main -->
@isset($item)
  @include("item")
@endisset
@forelse ($items as $item)
    @include("item")
@empty
    <p>No items</p>
@endforelse

Ну конечно вызовем

use Illuminate\Support\Facades\View;
return View::make('main', $data);

Теперь сделаем тоже самое на Blitz

<!-- item.tpl -->
<div class="item">{{ $name }}</div>
<!-- main.tpl -->
{{ BEGIN item }}
  {{ include("item.tpl") }}
{{ END }}
{{ IF $items }}
  {{ BEGIN items }}
    {{ include("item.tpl") }}
  {{ END }}
{{ ELSE }}
  <p>No items</p>
{{ END if-items }}

Вызовем, пусть нативно даже

$template = new \Blitz('main');
return $template->parse($data);

Много разницы? Мне кажется никакой. Что тут может быть непонятного?

Да неважно, возьмите тупой пример

{{ $some_flag ? $one : $two }}

Если $some_flag не определена, будет ошибка

А где вы увидели в блице php-код? Как раз таки только логика отображения, и никакого php-кода. И два раза как раз ничего писать не надо

Вы не поверите, ни разу не использовали в 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. Но к теме это не относится :-)

{{ ($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,'',', ') }} в циклах

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity

Specialization

Backend Developer, HTML Coding
Middle
Git
JavaScript
HTML
CSS
Adaptive layout
Web development
JQuery