seriousCustomTemplate v0.3

Вышло обновление для моего пакета с кастомным обработчиком шаблонов. Оно упоминалось в этой статье в качестве примера, как можно расширять ядро и добавлять контроллеры. Фактически сейчас это дополнение превратилось в пакет который устанавливается через composer.
Вначале я опишу зачем это всё сделано. А часть о том, что нового по сравнению с первой версией, расположена в самом конце текста.

Что всё это даёт и зачем оно вообще надо?
  1. Цель этого решения не убить сниппеты как таковы. Цель убить вызовы сниппетов из blade шаблонов.
  2. Добавить возможность передачи данных в шаблон таким образом, чтобы они были видны в tracy.
  3. Дать возможность через файлы управлять контентом который уходит в наш шаблон.

Убить вызовы сниппетов из blade шаблонов.
Наверняка возникнет резонный вопрос, зачем нам убивать то что у нас всегда работало? Ответ довольно простой. Все вызовы сниппетов прямо из шаблонов blade у нас никак не кешируются. Т.е. фактически вам приходится каждый раз выполнять одни и те же сниппеты, чтобы построить меню и вывести данные из pagebuilder, вывести какую-либо другую информацию через DocLister. Вы можете возразить, что в DocLister есть встроенный кэшер, но он в 2.0 не работает без установленного дополнения. И не все задачи решает DocLister. Формирование данных в файлах контроллеров позволяет кэшировать какие угодно данные и как душе угодно

Добавить возможность передачи данных в шаблон таким образом, чтобы они были видны в tracy.
Основной плюс, все данные которые мы передаём, мы можем видеть в виде переменных. Это немного да упрощает разработку. В ходе обсуждения возникали предложения, что раньше можно было сделать то же самое, только плагином и набросать всё что надо в placeholder-ы.
Пожалуй, тут стоит ответить на вопрос “В чём разница между набросать в плейсхолдеры через плагин и передать данные в шаблон”?
Передавая данные в плейсхолдер, мы их не увидим в отладчике.
Передавай данные в шаблон, мы их будем видеть в отладчике.

Да, из плагина можно передать данные в шаблон. Но это получается, вам нужен плагин который сам распределит в зависимости от каких-либо данных, как формировать данные и как их передавать. И это нас подводит к 3 пункту.

Дать возможность через файлы управлять контентом который уходит в наш шаблон.
Контроллеры завязаны строго на логику alias шаблона -> контроллер.
Т.е. фактически вся логика формирования строго завязана на шаблоны и вам уже ничего не надо придумывать. Например для шаблона список новостей с alias “lists.news”. Файл шаблона у нас будет лежать в views/lists/news.blade.php
А контроллер возьмётся из Controllers\Lists\NewsController.php
Новое разделение
То что всё у нас завязано на файлы, даёт нам возможность писать всё что нам необходимо прямо в IDE или любом редакторе. Без надобности использовать админку. Да ранее можно было создать сниппет/плагин, который подключит файл, и делать то же самое. Но в этой ситуации мы избавляемся от лишней прослойки.
Так как процесс вызова сниппета проходит примерно такой путь:
  1. Находим сниппет в коде шаблона;
  2. Вызываем его;
  3. Ищем в базе(опциональный шаг, код сниппета может быть в кэше);
  4. После того как он отработает, отправляем данные в шаблон.
  5. Повторно проходим парсером, на поиск вложенных сниппетов.

В случае когда мы используем контроллер:
  1. Инициализируем класс в зависимости от шаблона.
  2. После того как код отработает, отправляем данные в шаблон.

А если у нас не один сниппет, а несколько, то шаги 1-3 будут повторяться ровно столько раз, сколько у нас сниппетов будет вызвано прямо в шаблоне.

Что нового по сравнению со старой версией?
Изменение фактически всего одно. Добавлена поддержка alias указанных через точку, т.е. теперь namespace формируется с небольшим преобразованием. И фактически структура данных получила однотипный вид.
Новое разделение

Мини инструкция о том как создать свой пакет который будет работать вместе с моим дополнением.
Нам необходимо чтобы обязательно был BaseController, это так называемая обёртка, через которую мы будем управлять нашими общими данными, кэшированием и прочими вещами. В качестве основы можно взять пример из моего компонента или из Example package. Все остальные контроллеры по желанию могут либо наследовать BaseController, либо быть независимыми. Тут уже всё упирается в ваше желание.
Чтобы наша система увидела Ваши контроллеры, нам необходимо указать composer из какой папки и под каким namespace их прогрузить. Опять же можно обратится к Example package.
И после того как их прописали, необходимо выполнить сomposer upd
И финальным штрихом, для того чтобы моё решение знало из какого namespace брать контроллеры, необходимо просто прописать в массив конфига переменную с указанием namespace.

p.s. В дальнейшем моё дополнение будет развиваться в сторону вырезания из ядра некоторых вещей которые абсолютно не нужны для работы с шаблонизатором blade. И упрощения пути формирования документа.
Взять пакет можно здесь

1 комментарий

avatar
Благодарю за статью. Я созрел для того, чтобы покопаться в «кухне» Laravel / Blade / Evo 2.0, буду копаться.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.