Сравнение функционала шаблонов и Manage display

Аватар пользователя isuvar

Сейчас начал изучать twig и попутно возникают вопросы. Понятно, что мышкой в Manage display нельзя сделать всего того, что можно реализовать кодируя в twig-файлах, но можно ли сказать, что twig-файл (шаблон) это всего лишь более продвинутый аналог вкладки Manage display?
Помимо того, что в шаблонах поля располагаем на странице через код, а на вкладке Manage display мышкой настраиваем отображение и расположение полей, чем кардинально отличаются эти два интерфейса? Что можно сделать через один интерфейс и нельзя сделать через другой?
К сожалению в сети мало доступной инфы на русском языке и если можете дать ссылки на полезные ресурсы, был бы благодарен.

Тип материала:
Версия Drupal:
0 Thanks

Комментарии

Аватар пользователя VasyOK
VasyOK 1 неделя назад

"в Manage display нельзя сделать всего того, что можно реализовать кодируя в twig-файлах".
Сказать можно, но лучше такую фигню не нести.
Да. Но кроме Manage display есть еще много разных способов сделать что-то разными модулями. При этом не особо кодируя.

Аватар пользователя voviko
voviko 1 неделя назад

можно ли сказать, что twig-файл (шаблон) это всего лишь более продвинутый аналог вкладки Manage display?

Вы хрен с пальцем сравниваете.

Аватар пользователя adano
adano 1 неделя назад

Это холиварная тема. Темизация vs мышкокликеров.

Первые живут тут - https://www.drupal.org/docs/8/theming
Вторые - в панельках, DS, параграфах, Layout Builder и т.д.

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

Аватар пользователя gun_dose
gun_dose 1 неделя назад

Гомнокодят как раз первые, ибо когда весь вывод захардкожен в шаблоне, это полный идиотизм. Потом добавляешь новое поле в сущность, настраиваешь вывод, а оно не выводится. Бывают конечно адекватные люди, которые пару полей захардкодят, а остальное выводят через {{ content|without() }}, но таких людей в природе не очень много.

Аватар пользователя adano
adano 1 неделя назад

В корне не согласен. Реальный, простой кейс: контент в табах... Ну не дам я тебе вывод поля, где тебе захочется.

Аватар пользователя gun_dose
gun_dose 1 неделя назад

 field_group и не надо никаких шаблонов.

Аватар пользователя adano
adano 1 неделя назад

Ну вот он и с другой стороны идиотизм, когда костылишь контриб программно и/или по стилям/скриптам.
А в первом случае ~20 строк кода, вместе со скриптом.

Аватар пользователя gun_dose
gun_dose 1 неделя назад

Что значит "костылишь контриб"?

Аватар пользователя adano
adano 1 неделя назад

Это значит модуль не удовлетворяет потребностям ТЗ.

Аватар пользователя gun_dose
gun_dose 1 неделя назад

Почему не удовлетворяет? Он из коробки умеет делать табы.

Аватар пользователя adano
adano 1 неделя назад

Сотни причин могут быть. От специфического вывода контента (не поля), до поведения при линках и пустых значениях...

Аватар пользователя gun_dose
gun_dose 1 неделя назад

Когда начинается что-то очень специфическое, тогда можно уже кодить. А пока всё в рамках стандартных ситуаций, то лучший код - это тот, который не пришлось писать.

Однако, в рамках текущего обсуждения, очень сомнительно кодить в твиге вывод "специфического вывода контента (не поля)". Тут как минимум нужно ещё и препроцессы писать, либо кастомный форматтер - и то, и другое выходит за рамки "функционала шаблонов"

Аватар пользователя adano
adano 1 неделя назад

А кто говорит про "кодить в твиге"? Drupal-way - это даже не обсуждаемо.
Это и есть стандартная ситуация: "Есть контент, хочу его в табы..."
Это препроцессы то уходят за рамки шаблонов? ))

Аватар пользователя gun_dose
gun_dose 1 неделя назад

Немного уходят. А ещё частенько в препроцессах уходят от друпал-вэя))

Аватар пользователя P.Selfin@drupal.org
P.Selfin@drupal.org 1 неделя назад
gun_dose написал:
когда весь вывод захардкожен в шаблоне

Такое особенно любят на темфорестах.
И разумеется побольше темплейтов что на типы контента, что на урлы. Потом дебажишь это, отлавливаешь, и переверстываешь...

Аватар пользователя gun_dose
gun_dose 1 неделя назад
3

Зато в резюме пометка "не кликер"))))

Аватар пользователя adano
adano 1 неделя назад
isuvar написал:
Что можно сделать через один интерфейс и нельзя сделать через другой?

Примерный кейс: вывод аббревиатур значений поля (List) отдельно для тизера и полной ноды...

Аватар пользователя VasyOK
VasyOK 1 неделя назад
adano написал:
Темизация vs мышкокликеров.
Первые живут тут - https://www.drupal.org/docs/8/theming

Вторые - в панельках, DS, параграфах, Layout Builder и т.д.

Не нужно пытаться классифицировать друпалеров. Я кликбилдер, но не пользуюсь (на своих сайтах) чем пользуются "вторые". В шаблоны в основном добавляю контейнеры. И прогеры, которые пользуются panels тут тоже есть.

Аватар пользователя adano
adano 1 неделя назад

Бред. Еще как нужно классифицировать. Ты же свою ставку озвучить можешь...

Аватар пользователя Orion76
Orion76 1 неделя назад

Если мышка экономит время и нервы - то я за мышку (DisplaySuite + Fieldgroup + CSS)
Если мышка тратит время и нервы - ну её нафик, ту мышку-)

Короче, все зависит от задачи.

Аватар пользователя sas@drupal.org
sas@drupal.org 1 неделя назад

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

Аватар пользователя Phantom63rus
Phantom63rus 1 неделя назад
3

Чем больше кастомного кода тем больше геморроя с поддержкой.

Аватар пользователя Orion76
Orion76 1 неделя назад

Да.. люди любят все делить на 2..
Это проще чем делить на 3 или на 7.5 или на 100500.
Особенно в двоичной системе-))

Аватар пользователя isuvar
isuvar 1 неделя назад

John Jennings в лекции Theming with Twig in Drupal 8 , если судить по слайдам (английский на слух не понимаю), видимо также говорит о Twig и Manage display.

Аватар пользователя isuvar
isuvar 1 неделя назад
isuvar написал:
twig-файл (шаблон) это всего лишь более продвинутый аналог вкладки Manage display

Видимо лучше сказать, что Manage display (включая функционал модулей типа DS и др., расширяющих возможности редактирования макета во вкладке Manage display) - это Drag-and-drop редактор, являющийся надстройкой над twig-файлом.
Как и любая надстройка (еще один дополнительный интерфейс для разработчика) Manage display позволяет что-то сделать быстрее и проще, но при этом не предоставляет все возможности интерфейсов более низкого уровня, в данном случае - возможностей, имеющихся при непосредственном редактировании twig-файлов.
Следовательно, если не удается сделать желаемое на уровне Manage display (+ доп. модули), то придется опускаться на уровень ниже - начинать кодить в twig-файле, либо писать custom-модуль, который бы добавил необходимый нам функционал к Manage display.