23 августа 2018 в 12:34
Друпал-мастера не рекомендуют пихать код в шаблон. В связи с этим имею вопрос: где и как можно писать код под следующую логику:
В дисплее ноды (full) сразу под body необходимо разместить несколько кнопок (субмитить их не надо, обработка js по onclick), при этом необходимо выполнить проверки значений некоторых полей ноды, ролей юзера и т.п., это влияет на количество и состав отображаемых кнопок.
В принципе, всё указанное уже работает в page--nodetype.tpl.php вполне нормально, но, судя по разного рода мнениям, это неправильный путь.
Комментарии
Забейте на мнения. Вы для себя сайт делаете или для кого-то? Этот кто-то вам альтернтаивный путь может объяснить?
По делу. Несколько кнопок можно поместить в блок. А в блоке уже код нагородить. Использовать PHP фильтр - точно не правильно. Зато без генерации кода в шаблоне.
За этим и обратился.
А как же тогда городить код в блоке, не используя PHP?
Не код, а логику.
Есть смысл JS'ом и строить, если они только ради этого.
Есть разные возможности вывода необходимых данных на страницу - от передачи настроек, до установки аттрибутов.
В первую очередь, нужно руководствоваться здравым смыслом.
Держать код в поддерживаемом и понятном состоянии, соответствии стандартам системы и текущих практик в индустрии.
Периодически, рефакторить, тем самым улучшая его качества.
Ну, и задаваться подобными вопросами - это верный путь.
Чтобы выносить код из шаблонов можно использовать препроцесс функции в template.php
https://api.drupal.org/api/drupal/modules%21node%21node.module/function/...
Например в вашем случае что-то вроде
// здесь ваша логика, формируем HTML
// и дальше добавляем его после body
$variables['content']['body']['#suffix'] = '<div>Какой-то результирующий HMTL</div>';
}
Вот не нужно так делать!
Код (HTML) должен быть в шаблонах.
В препроцессоре можно сделать проверку на, например, необходимость вывода этого суффикса.
В целом, "шаблоны" это же не просто слово - там должно находится все что можно использовать в качестве лекала. Все остальное, динамическое - должно приходить в качестве переменных.
Поддерживаю. В препроцессоре должны приготавливаться переменные! А обёртывать их нужно в шаблоне
В принципе, соглашусь. Тогда, если задача стоит разместить кнопки именно после body и при этом логика достаточно сложная, что есть смысл вынести ее из шаблона, то можно вынести ее в template_preprocess_field(), там проверять какие конкретно кнопки нужны, а HTML код кнопок уже выводить в field--body--content-type.tpl.php в зависимости от состояния кастомных переменных. Как вам такой вариант?
Или другой вариант, в препроцессоре проверять условия и формировать массив нужных кнопок в виде render arrray, а потом передавать его в шаблон и там выводить при помощи render(). Или это тоже будет не правильно?
Не понимаю о каких кнопках речь. Такой подход верный.
Код в шаблоне городить можно и нужно. Программисты затем и используют файлы, чтобы городить в них код. Но не всякий код одинаково полезен. Звучала мысль, что нельзя логику пихать в шаблон, это верно лишь отчасти, тут нужно уточнение: логические операторы вроде if, а также циклы foreach в шаблоне очень даже уместны. Уместны в шаблоне простые функции конкатенации, арифметические операции, функции форматирования (например round), а также всякие str_replace и прочее.
Неуместно только вот что: любые действия, нарушающие последовательность вывода по mvc-модели. Логика ведь такая: запросили данные из базы, обработали их, сформировали из них рендер-массив, передали его в шаблон, а шаблон уже должен нам отдать html-строку. То есть любая операция, которая не запрашивает данные из БД, теоретически уместна в шаблоне. Можно пойти дальше и продолжить эту цепочку, что операции, вызывающие функции темизации, также неуместны в шаблоне, но на практике этого хоть и стараются избегать, но всё же иногда используют, если речь не о друпал 8.
А именно в друпал 8 twig бьёт всех линейкой по рукам, не давая проворачивать такую дичь, там уже хочешь - не хочешь, а придётся делать по-нормальному. Хотя вроде бы всякие двоечники изобрели какие-то модули для бесчинств в твиге.
Отвечая на вопрос автора скажу вот что: эти кнопки без зазрения совести можно спокойно помещать в шаблон. А вот в шаблон ноды или поля - тут надо думать, ведь хардкодить последовательность полей в шаблоне ноды - моветон. Хотя всегда есть компромисное решение - захардкодить несколько принципиально важных полей, а остальные вывести через print render($content);
PS: всегда надо следить за тем, чтобы шаблон не раздувался. Хрестоматийный случай в моей практике: сайт делал глянец, шаблон node.tpl.php, а там if ($node->type ==.... и далее набор условий под все типы нод, в результате чего в шаблоне около 3000 строк, а если добавить новый тип ноды, то его вывод всегда пустой ?
Уточню, действительно непонятно написал - под "логикой" имел ввиду "бизнес-логику" приложения (т.е. все что нужно высчитать / вычислить, связать с экстра-сущностями, получить из других источников или произвести обработку со значительными затратами процессорного времени).
Не зря ведь весь прогрессивный мир старается следовать петтернам из разряда MVC.
Но в таком монолите как Друпал очень сложно соорудить систему полностью следующей этой парадигме. Потому следуем в ближайшие заведения питейно-развлекательного характера.
С пятницей, кароч!
Про логику в теме оформления уже написали много и правильно, добавлю следующее.
Следует различать логику, реализуемую в теме, и логику, реализуемую модулями.
Проще всего это сделать, мысленно представив, что на сайте есть несколько тем оформления, между которыми пользователь может переключаться: для левшей-правшей, близоруких-дальнозорких, ну и т.д.
Если логика будет одинакова для всех тем оформления, то её следует реализовывать модулем, а если нет, т.е. она относится именно к представлению данных для отдельной темы оформления - то тогда её надо реализовывать в теме.
Ибо, тема - это V в парадигме mvc, а модуль - как раз-таки C (но это не точно).