Есть страница новостей url = "/articles" layout = "default" Можно ли в самом

шаблоне default.htm
вставить в нужном месте
{% placeholder breadcrumb %}

и тут же.. (в самом низу) подключить breadcrumb ?
{% put breadcrumb %}
{% if this.page.id != 'frontpage' %}
{% partial 'breadcrumbs'%}
{% endif %}
{% endput %}

Просто сейчас на странице articles не подключилась навигация. Это нужно для того, чтоб не подключать на каждой странице {% put breadcrumb %}
Также чтоб уменьшить кол-во запросов на страницу.

{% placeholder breadcrumbs default %} Все что тут будет отображено по умолчанию на всех страницах {% endplaceholder %}

Но я бы честно сказать сделал это через партиал. {% if links is not empty %} <div class="breadcrumbs"> <div class="breadcrumbs__links"> <a href="/" class="breadcrumbs__links-item">Главная</a> {% for link in links %} <a href="{{ url }}" class="breadcrumbs__links-item {{ (loop.last) ? '—active' }}">{{ name }}</a> {% endfor %} </div> </div> {% endif %} {% partial 'layout/breadcrumbs' links=[{ name: 'Блог', url: 'blog/posts' | page }, { name: 'Как накачать бицуху как сталоне' } ] %}

+ Не знаю, правильно ли вообще так писать в самом макете default? Но по крайней мере работает {# Хлебные крошки #} {% put breadcrumb %} {% if this.page.id != 'frontpage' %} {% partial 'breadcrumbs'%} {% endif %} {% endput %} {% placeholder breadcrumb %}

В начале в общем и размещал через partial, но сказали, что надо теперь через put это сделать. Не вижу в принципе разницу, каким боком это уменьшит запросы на страницах, тоже не понятно.

Я как то слышал от одного человека года 2 назад. Что ни в коем случае нельзя все дробить на кусочки (фрагменты, партиалы и тд). Ведь бедный php это же инклюдит, а это тратил столько то времени. Но собеседник не учитывает наличие ssd почти в любой железяке и тот факт, что шаблоны кешируются блять) Так что не совсем понятно что имелось ввиду под запросами в твоем случае. Ты данные по сути берешь из файла, фактически это статика. Если бы крошки брались из бд то был бы запрос. Но я пока не видел таких крошек))

Ну не дробить на кусочки лучше из других соображений. Дробить надо так, чтобы следовать DRY в идеале, не все и вся по желанию. Вдобавок не стоит дробить на input’ы.. так как есть form_* методы в твиг, для реализации инпутов разных типов.

А что там такого, что через метод не добавить? Те же аттрибуты, те же данные. Все добавляется

Там например x-model, x-init, @click.prevent и тд

{{ form_text('example', null, {'x-model': 'model'}) }}

Владимир всегда в поиске истины)) На самом деле поля с того же альпайна даже через партиал неудобно вызывать. Бывает что надо ебануть лапшу js кода, например в alpine v2 не была доступна this.$el в биндах. Это очень огорчало. Приходилось делать так: <input type="text" name="penis_height" value="{{ penis_height }}" x-init="fields.penis_height = {{ penis_height }}"> В целом такую констуктевину можно сунуть в partial и передавать нужные атрибуты Можно и через форм хелпер вызвать, но в таком случае для каждого вызова придется написать это: x-init="fields.penis_height = {{ penis_height }}"

Лапша js кода? Возможно стоит пересмотреть структурирвоание ?

Нет именно присвоить модели значение нельзя было в отдельном компоненте в alpine v2 Сейчас уже 3 версия и там можно ебануть прям в компоненте более элегантно: bindField: { let value = this.$el.value, model = this.$el.getAttribute('name'); this.fields[model] = value; } <input name="penis_height" type="text" x-bind="bindField" value="{{ penis_height }}">

Все-равно не понимаю проблемы инструмента. FormBuilder лишь абстракция над типовым html форм. Альпин спокойно дружит и 2, и 3 версии. Лапшу пока не приходилось делать.

А по поводу лапши зависит от задачи. Если делать на каждый чих компонент, то все будет красиво и славно. Правда кода вагон писать. Если нужно универсально Аля cms, crm когда однотипные листинги и формы, тут немного иначе.

не всегда... видел я проект, где было куча компонентов... ух жесть

не знаю, cms, crm, делал, и однотипные листинги и даже лапши не было и вагона кода не было ) Возможно я не правильно делал, надо будет позже документации еще раз пролистать.

У меня такой есть. Наверное штук 20) tabs.js team_form.js team_list.js ... На каждую хрень по сути) работает хорошо, красиво но меня потом от джаваскрипт тошнило)

не.. я видел crm . там компонентов было под сотню

Могу скинуть гит на свой проект, глянешь опытным глазом. Я не претендую на то, что я не ебаться какой программист и у меня все юзерфул. День от дня захожу чищу лишнее в компонентах. У меня самое интересное сейчас есть абсолютно 2 одинаковые, недописанные crm одна чисто на alpine.js другая на alpine + livewire

Тогда вопрос - зачем тебе 2 CRM ?)

что за вопросы у каждого прогера должна быть своя crm

но не две же )

а это еще лучше

Это может быть неплохо на самом деле. Да это не dry зато сохраняется принцип единой ответственности и можно гибко менять под задачи. Но я бы выбрал наследование, иначе до седых седин поддерживать это все)

Смотря каких… Например один Column компонент того же filament, один, но переиспользуемый.

Это одна crm я исследовал технологии. Они визуально одинаковы. 1. Пробовал alpine + resourse контролёры. Там есть один Backend контроллер остальные его наследуют. 2. alpine + livewire Есть мастер компоненты RecordList, RecordForm остальные его наследуют. Контролёров как таковых нет) Просто писал одну, понял что в связке alpine + контроллеры тяжко, решил махнуть технологии

alpine так крут ? часто просто стал видеть что юзают

Да. Он крут тем, что это не vue.js) Он работает в реальном дом дереве и вполне неплохо может получать данные прямо в шаблоне. У него крошечный размер при этом. Для рядовых проектов сайты, магазины и ТД. Ну просто пушка. Особенно когда в магазине надо развернуть каталог с фильтрами, пагинацией, сортировкой и ТД. С ним эта задача очень простая Из минусов гадит в дом дерево. Валидатор html ругается

>Из минусов гадит в дом дерево. Мы на некоторых проектах динамически прокидывали x-атрибуты на нужные ноды, чтобы не портить разметку. Вроде и звучит как изврат, но в целом получалось более читаемо и поддерживаемо, чем если бы залепили всё это в HTML