Сейчас начал изучать twig и попутно возникают вопросы. Понятно, что мышкой в Manage display нельзя сделать всего того, что можно реализовать кодируя в twig-файлах, но можно ли сказать, что twig-файл (шаблон) это всего лишь более продвинутый аналог вкладки Manage display?
Помимо того, что в шаблонах поля располагаем на странице через код, а на вкладке Manage display мышкой настраиваем отображение и расположение полей, чем кардинально отличаются эти два интерфейса? Что можно сделать через один интерфейс и нельзя сделать через другой?
К сожалению в сети мало доступной инфы на русском языке и если можете дать ссылки на полезные ресурсы, был бы благодарен.
Комментарии
"в Manage display нельзя сделать всего того, что можно реализовать кодируя в twig-файлах".
Сказать можно, но лучше такую фигню не нести.Да. Но кроме Manage display есть еще много разных способов сделать что-то разными модулями. При этом не особо кодируя.
Вы хрен с пальцем сравниваете.
Это холиварная тема. Темизация vs мышкокликеров.
Первые живут тут - https://www.drupal.org/docs/8/theming
Вторые - в панельках, DS, параграфах, Layout Builder и т.д.
Суть в том, что вторые иногда пытаются стать первыми и гомнокодят в шаблонах.
Но первые, никогда не пытаются стать вторыми. ?
Гомнокодят как раз первые, ибо когда весь вывод захардкожен в шаблоне, это полный идиотизм. Потом добавляешь новое поле в сущность, настраиваешь вывод, а оно не выводится. Бывают конечно адекватные люди, которые пару полей захардкодят, а остальное выводят через {{ content|without() }}, но таких людей в природе не очень много.
В корне не согласен. Реальный, простой кейс: контент в табах... Ну не дам я тебе вывод поля, где тебе захочется.
field_group и не надо никаких шаблонов.
Ну вот он и с другой стороны идиотизм, когда костылишь контриб программно и/или по стилям/скриптам.
А в первом случае ~20 строк кода, вместе со скриптом.
Что значит "костылишь контриб"?
Это значит модуль не удовлетворяет потребностям ТЗ.
Почему не удовлетворяет? Он из коробки умеет делать табы.
Сотни причин могут быть. От специфического вывода контента (не поля), до поведения при линках и пустых значениях...
Когда начинается что-то очень специфическое, тогда можно уже кодить. А пока всё в рамках стандартных ситуаций, то лучший код - это тот, который не пришлось писать.
Однако, в рамках текущего обсуждения, очень сомнительно кодить в твиге вывод "специфического вывода контента (не поля)". Тут как минимум нужно ещё и препроцессы писать, либо кастомный форматтер - и то, и другое выходит за рамки "функционала шаблонов"
А кто говорит про "кодить в твиге"? Drupal-way - это даже не обсуждаемо.
Это и есть стандартная ситуация: "Есть контент, хочу его в табы..."
Это препроцессы то уходят за рамки шаблонов? ))
Немного уходят. А ещё частенько в препроцессах уходят от друпал-вэя))
Такое особенно любят на темфорестах.
И разумеется побольше темплейтов что на типы контента, что на урлы. Потом дебажишь это, отлавливаешь, и переверстываешь...
Зато в резюме пометка "не кликер"))))
Примерный кейс: вывод аббревиатур значений поля (List) отдельно для тизера и полной ноды...
Не нужно пытаться классифицировать друпалеров. Я кликбилдер, но не пользуюсь (на своих сайтах) чем пользуются "вторые". В шаблоны в основном добавляю контейнеры. И прогеры, которые пользуются panels тут тоже есть.
Бред. Еще как нужно классифицировать. Ты же свою ставку озвучить можешь...
Если мышка экономит время и нервы - то я за мышку (DisplaySuite + Fieldgroup + CSS)
Если мышка тратит время и нервы - ну её нафик, ту мышку-)
Короче, все зависит от задачи.
Как по мне важное значение имеет скорость решения задачи и для долгоиграющих проектов - масштабируемость, друпал вай тоже хорошо, но он не догма.
Чем больше кастомного кода тем больше геморроя с поддержкой.
Да.. люди любят все делить на 2..
Это проще чем делить на 3 или на 7.5 или на 100500.
Особенно в двоичной системе-))
John Jennings в лекции Theming with Twig in Drupal 8 , если судить по слайдам (английский на слух не понимаю), видимо также говорит о Twig и Manage display.
Видимо лучше сказать, что Manage display (включая функционал модулей типа DS и др., расширяющих возможности редактирования макета во вкладке Manage display) - это Drag-and-drop редактор, являющийся надстройкой над twig-файлом.
Как и любая надстройка (еще один дополнительный интерфейс для разработчика) Manage display позволяет что-то сделать быстрее и проще, но при этом не предоставляет все возможности интерфейсов более низкого уровня, в данном случае - возможностей, имеющихся при непосредственном редактировании twig-файлов.
Следовательно, если не удается сделать желаемое на уровне Manage display (+ доп. модули), то придется опускаться на уровень ниже - начинать кодить в twig-файле, либо писать custom-модуль, который бы добавил необходимый нам функционал к Manage display.