Последнее время на меня валится большое количество шаблонных проектов и становится скучно. Приходится развлекаться на стороне =)
Сразу оговорюсь - подключение к битриксу шаблонизатора это скорее теоретические изыскание, на практике нигде не применял, поэтому особенно интересно мнение сообщества - какие вы видите в этом плюсы и минусы. Также цель поста - попиарить проект
Итак - начнем. Подключить шаблонизатор к битрикс довольно просто - надо задать глобальную переменную arCustomTemplateEngines и описать в ней используемые шаблонизаторы с привязкой к расширениям, в общих чертах делается это так:
$loader = new \Twig_Loader_Filesystem(array($_SERVER['DOCUMENT_ROOT'])); $GLOBALS['twig'] = new \Twig_Environment($loader,array( 'debug' => true, )); $GLOBALS['twig']->addExtension(new \Twig_Extension_Debug()); function twigRender($templateFile, $arResult, $arParams, $arLangMessages, $templateFolder, $parentTemplateFolder, $template){ $arResult['PARAMS']=$arParams; echo $GLOBALS['twig']->render($templateFile,$arResult); } |
В общих чертах, зачем это может быть нужно.
Плюсы
- Более лаконичный синтаксис, по сравнению с php-шаблонами
- Отсутствие соблазнов использовать в шаблоне выборку и обработку данных
- Расширяемость - очень легко задавать собственные функции, фильтры и даже лексемы
- Синтаксис php знают все, синтаксис twig необходимо учить
- php-шаблоны отрабатывают быстрее, но с учетом что все и так держится на кэшировании - не очень большой минус
- Битрикс поддерживает шаблонизаторы только для компонентов, шаблоны сайтов все равно останутся в php
<div class="news-list"> {%if PARAMS.DISPLAY_TOP_PAGER=="Y" %} {{ NAV_STRING | raw }}<br> {%endif%} {%for item in ITEMS%} {{ AddBitrixActions(item) }} <p class="news-item" id="{{ GetEditAreaId(item) }}"> {% if PARAMS.DISPLAY_PICTURE != "N" and item.PREVIEW_PICTURE is iterable %} {% if not PARAMS.HIDE_LINK_WHEN_NO_DETAIL or (item.DETAIL_TEXT and USER_HAVE_ACCESS) %} <a href="{{ item.DETAIL_PAGE_URL }}"> {{ ResizeImageView(item.PREVIEW_PICTURE.ID,100,100,{'class':'preview_picture','alt':item.PREVIEW_PICTURE.TITLE}) | raw }} </a> {% else %} {{ ResizeImageView(item.PREVIEW_PICTURE.ID,50,50,{'class':'preview_picture','alt':item.PREVIEW_PICTURE.TITLE}) | raw }} {% endif %} {% endif %} {% if PARAMS.DISPLAY_DATE!="N" and item.DISPLAY_ACTIVE_FROM %} <span class="news-date-time">{{ item.DISPLAY_ACTIVE_FROM }}</span> {% endif %} {% if PARAMS.DISPLAY_NAME!="N" and item.NAME %} {% if PARAMS.HIDE_LINK_WHEN_NO_DETAIL or (item.DETAIL_TEXT and USER_HAVE_ACCESS) %} <a href="{{ item.DETAIL_PAGE_URL }}"><b>{{ item.NAME }}</b></a><br /> {% else %} <b>{{ item.NAME }}</b><br> {% endif %} {% endif %} {% if PARAMS.DISPLAY_PREVIEW_TEXT!="N" and item.PREVIEW_TEXT %} {{ item.PREVIEW_TEXT }} {% endif %} {% if PARAMS.DISPLAY_PICTURE!="N" and item.PREVIEW_PICTURE is iterable %} <div style="clear: both;"></div> {% endif %} {% for property in item.DISPLAY_PROPERTIES %} <small> {{ property.NAME }}: {% if(property.DISPLAY_VALUE is iterable) %} {{ property.DISPLAY_VALUE | join(" / ") }} {% else %} property.DISPLAY_VALUE {% endif %} </small><br> {% endfor %} </p> {%endfor%} {%if PARAMS.DISPLAY_BOTTOM_PAGER=="Y"%} {{ NAV_STRING | raw }}<br> {%endif%} </div> |
С примерами, пожалуйста.
По поводу шаблонизаторов - у меня однозначное мнение: PHP - и есть шаблонизатор, зачем еще одна абстракция/обертка?
Один вопрос. На кой оно в битриксе?
Пример из жизни: необходимо дать возможность верстальщику или специально обученному оператору создавать произвольные промо-страницы с использованием динамических данных (информация о товарах, новости). Тут три очевидных решения:
1) Сотрудник решает задачу под контролем программиста. В этом случае риски малы, но тратится дорогое время программиста;
2) Сотрудник решает задачу самостоятельно, создавая шаблоны на PHP. В этом случае риски высоки: человеку с недостаточной квалификацией дается доступ к серьезным инструментам. Рано или поздно это может закончится строчкой $DB->Query("DROP DATABASE ...
3) Сотрудник решает задачу самостоятельно, создавая код для шаблонизаторов.
В последнем случае отсутствуют минусы первых двух: программист не требуется, а доступные инструменты ограничены базовыми операциями (if, foreach). Кроме того, как показывает практика, операторы почему-то лучше и быстрее воспринимают синтаксис шаблонизатора, чем PHP.
Это лишь один из примеров.
Хотя нестандартные шаблонизаторы в контексте Битрикс оказываются кстати не так уж и часто, тем не менее это полезный функционал.
Сейчас рассматриваем вариант создания системы при которой программист и верстальщик могут одновременно начинать работу над проектом, и в идеале когда закончит верстать верстальщик - в этот-же момент закончит работать и программист, и сайт будет готов к сдаче клиенту.
Плюсы очевидны - программист занимается тем для чего предназначен - созданием логики и входных данных, а верстальщик - делает свою работу - красиво выводит входные данные через циклы. Но на практике далеко не все так красиво и радужно.
Есть ли у вас идеи, как прикрутить шаблонизатор к header.php и footer.php? может быть делать эту обработку через OnEpilog или onEndBufferContent обрабатывая и подставляя новые обработанные данные в вывод?
Пробовал заказывать верстку на стороне - сплошной фейспалм
Левый Иван, еще проще, когда верстальщик и программист - один и тот же человек почти всегда так работал - свою верстку проще интегрировать.
Пробовал заказывать верстку на стороне - сплошной фейспалм
Это так, но на практике выходит в разы быстрее когда это разные люди.
Верстальщик профессионально верстает шаблон с использованием современных технологий (foundation, less, nodeJS адаптивность, кроссбраузерность и тд) которые программисту мало интересны, а программист - программирует на основе АПИ Битиркса, затоговок и библиотек, которые верстальщику знать нет надобности.
Иван, это можно делать и без шаблонизаторов. Был положительный опыт, при котором верстальщики вполне легко ориентировались на проекте и правили ПХП-шаблоны. Сформулируйте ряд необходимых правил и соглашений, зафиксируйте и расскажите о них.
Я бы не сказал, что это "легко" для верстальщиков. Конечно, верстальщик средней толковости разберется что к чему, но на внесение правок у него будет уходить больше времени, чем если бы он делал правку в исходной чистой html-верстке.
Зерно рациональности в этом присутствует, причем большое. Но если еще и упростить способ расположения шаблонов (чтобы не копаться в подпапках 10-го уровня) и сделать проще создание разных типов страниц (не header.php и footer.php а только один файл шаблона) - то конечно, за этим будущее.
Наверное, я соглашусь, что верстальщикам-старообрядцам, не принимающим ничего нового, будет некомфортно копаться в шаблонах. Однако, если разобраться, сложностей в работе с аккуратно организованными шаблонами в Битрексе не больше, чем в написании среднестатистического ява-скрипта.
Что касается десяти уровней вложенности, никогда с таким не сталкивался, максимум 2-3. Почти всегда я складываю шаблоны компонентов только в каталог шаблона сайта, поэтому бегать по всей структуре проекта не приходится.
и сделать проще создание разных типов страниц (не header.php и footer.php а только один файл шаблона)
Потом программист эту верстку программирует.
Когда на проекте возникают доработки где нужно править рабочий код (например, изменился внешний вид страницы товара) то верстальщик вносит правки на своем сервере для верстки, и комитит изменния через систему контроля версий в Битбакет. Программист когда приступает к внесению правок - полностью перезаливает все стили и js с сервера верстки (так как изменений в них может вносить только верстальщик) и изменяет html-структуру запрограммированного шаблона (видя через историю контроля версий в каких местах вносились правки).
Как правило, это работает быстро и надежно и достаточно программиста даже начального уровня чтобы перенести правки с верстки на рабочий сервер. Но как всегда - хочется автоматизации, поэтмоу рассматриваем вариант когда даже такого ручного переноса не понадобится.
По поводу 10-ти уровней - я имел ввиду такую структуру:
/bitrix/templates/s1/components/bitrix/catalog/main-cat/bitrix/catalog.section/.default/template.php (тут даже 12 каталогов вышло)
поэтому ищем способ чтобы все шаблоны (все файлики /template.php) лежали в одном месте на проекте (максимум с одним уровнем вложенности), например, так:
/local/html_templates/
- prodlist.tpl
- category.tpl
- subcategory.tpl
- body.tpl
- feedback.tpl
- ... и тд
чтобы верстальщик видел все шаблоны в одной папочке, и для него было просто и комфортно их править.
Можно поподробнее, чем это поможет?
верстальщику проще править костяк шаблона когда это один файл (где видно структуру вложенности дивов), а если он должен помнить что в header.php он открыл 4 дива, и должен их закрыть в footer.php то это усложняет и запутывает разработку.
Вот вы говорите про объединение шапки и подвала в один файл. Честно, мне кажется, это надуманная проблема. «Чистая» вёрстка собирается отдельно (просто ХТМЛ-страницы или компилирование, не важно), а потом уже её куски перетаскивают в шаблоны. Копи-паст, в общем.
С шаблонами в /local/html_templates/, думаю, могут возникнуть подводные камни, если проект будет расти. Тут надо учитывать те же зоны компонентов, многосайтовость.
Тема автоматизации широка и интересна. Главное, автоматизируя, как минимум, не терять того функционала, который был ранее : )
Легко подключается через composer, psr-4 внутри, все дела ..