modxSmarty

Не буду особо про него расписывать, потому что не уверен, что этот пакет заинтересует широкие массы, но лично я его делал для себя и буду использовать много где.
Это не просто пакет, который инициализирует $modx->smarty. Он в себе еще содержит функции-плагины для смарти, позволяющие вызывать и обрабатывать MODX-элементы непосредственно в Smarty. К примеру: {snippet name=«Wayfinder»}
Таким образом непосредственно в Smarty-шаблоне будет выполнен Wayfinder.
Или {parser content=«HTML-code [[++site_url]] etc.»}
На выходе получим обработанный MODX-парсером контент.

У кого-то возникнет вопрос «Зачем парсить что-то внутри Smarty-шаблона, если все равно на выходе MODX обработает контент?».
1. MODX хранит довольно большой и хитрый кеш. А если у нас включено Smarty-кеширование и мы правильно им пользуемся, то у нас этот сниппет вызовется только один раз, а потом уже у нас просто конечный HTML, и MODX на это не будет напрягаться.
2., 3., 4. и т.д. — много личных причин так делать.

Исходник с билдером: github.com/Fi1osof/modxSmarty
Готовый пакет: sourceforge.net/projects/modxsmarty/

30 комментариев

avatar
Плагин замечательный, только есть одна проблемка — я так и не смог разобраться как его использовать :)
avatar
Мне видимо надо с ним сразу тестовый шаблон устанавливать, чтобы можно было тут же увидеть работу…
Суть его в том, что он сам как бы ничего не делает. Просто в своих любых фронтовых сниппетах можно использовать объект $modx->smarty (он автоматически на уровне плагина инициализируется). То есть программист сам решает где его использовать.
Но чтобы увидеть его работу уже сейчас, можно сделать пару действий:
1. Создаем шаблон с вызовом сниппета [[!Smarty]] (и ничего больше).
2. Создаем сниппет Smarty и пишем в нем
return $modx->smarty->fetch('index.tpl');

Все. Устанавливаем этот шаблон для любого документа и смотрим результат. Правда будет выведен не контент страницы, а именно тестовая страницы модуля с примерами использования, типа
Using MODX-elements via Smarty
Snippet

{snippet name=«SnippetName» params=«var=`value`&var2=`value`» parse=«true»}

parse — not necessary. If set 'true', output will be parsed by MODX-parser. Default — false

params — not necessary. Can use String or Array.

Далее посмотри системные настройки modxSmarty.template_dir и modxSmarty.template
Это, как ты догадался, путь к шаблонам и название используемого шаблона. Идея в том, чтобы обеспечить полную шаблонизацию сайта в целом. То есть создал свою папку шаблонов, создал свой шаблон и фигачь туда шаблоны сайта.

Минусы: минус всего этого в том, что как известно, MODX не использует php-код в шаблонах. То есть для работы этого все равно приходится вставлять хотя бы 1 сниппет в шаблон, который в итоге будет работать со смарти.
Я в связке с этим модулем использую phpTemplates. Обеспечивается максимальная скорость, а MODX-шаблоны превращаются в полноценные контроллеры.
avatar
Интересно, нужно будет затестить
avatar
Честно сказать сам не понимаю, почему пакет не юзают. Один из немногих, кто оценил этот пакет — @silentworks MODX Ambassador из Лондона. Он как раз заморочен вопросом прикручивания Twig-шаблонизатора к MODX-у, но он делал на уровне плагинов. Реализация phpTemplates и modxSmarty к нему его просто восхитила.
А так всего 45 скачиваний. Хотя в modxSmarty можно включить кеширование, и Smarty принимает на себя бОльшую часть нагрузки, полностью разгружая парсер MODX-а, а так же порой в десятки раз сокращая количество вызовов всяких чанков. К тому же кеш так можно продумать, что он будет глобальный для всех страниц сайта. Скорость загрузки страницы можно легко довести до 0.1 сек, а общий кеш в файлах по объему можно сократить в десятки раз.
avatar
Люди любят глазами, поэтому им нужны примеры, до и после, и как это всё завернуть в газетку и с собой забрать)
avatar
Честно сказать не рассчитывал на тех, кто со Смарти не работает. Рассчет был на тех, кто знает что это такое.
Но вот маленький пример на modxSmarty:

{snippet name=getDocuments params="parent=`0`" assign=docs}
{foreach from=docs item=doc}
<div>
    <h2>{$doc.pagetitle}</h2>
    <p>{$doc.introtext}</p>
</div>
{/foreach}
avatar
Интересно почему MODX написали свой «шаблонизатор»
avatar
Но админку свою, как известно, они на Смарти написали, а не на своем шаблонизаторе-парсере :-)
avatar
В админке можно было и без смарти обойтись, пхп не хуже работает как шаблонизатор
avatar
ИМХО хуже. Замена строк и все такое безусловно все ОК, но слишком сильно происходит визуальное смешивание PHP и HTML кода.
avatar
Точно, это ИМХО)
avatar
{snippet name=getDocuments params=«parent=`0`» assign=docs}
Разве это будет работать? Сниппет всегда возвращает строку, массив вернуть не может. По крайней мере через $snippet->process() (а значит и $modx->runSnippet() )
avatar
Да, верное замечание. Не будет. Ведь и сам топики на эту тему писал. Просто часто в своих проектах использовать метод runSnippet(), который как раз массивы умел возвращать.
Значит используем {processor} :)
avatar
Вот примерчик: сейчас сайт делаю, но там главная просто ппц. Одних только Wayfinder уже сейчас 8 вызовов на одной странице, плюс последние комменты Quip и еще хватает всего.
На кешируемых MODX-тегах страница отдается за 0.6-0.8 сек (из кеша, все закешированно).
Просто заменил все [[snippet]] на {snippet name=snippet} (то есть перевел на Смарти-теги), и из кеша страница сразу стала отдаваться за 0.1 сек. Разница и глазом очень сильно заметна.
Знаю точно, что еще могу с десяток сниппетов накидать, и производительность почти не упадет.
avatar
Весело)
avatar
Вот это уже что-то реальное. Больше таких примеров нужно.
И о подводных камнях тоже. Чтобы знать, на что можно нарваться и как этого избежать.
avatar
В целом пакет итак довольно стабильный, но пара мелочей есть еще. Я в ближайшем релизе пару правок сделаю и напишу подробный топик с примерами.
А в целом как бы и ничего не теряется. Все, что будет отработано на уровне Smarty-тегов ({snippet}, {chunk} и т.п.), то и будет управляться на уровне Смарти (кеш и все такое). А что не отработается (то есть будут использованы классические MODX-теги типа [[chunk]] и т.п.), то будет обработано на уровне MODX-парсера.
Эти моменты надо учитывать чисто на уровне планирования кеша.
avatar
А как с генерацией первый раз? Если из кеша 0.1, но кешируется 5 сек, тогда не вариант.
avatar
Это уже от многих моментов зависит. У меня первая генерация около 1 секунды (то есть и Смарти, и MODX, все до кучи).
Но здесь есть принципиальное отличие: в MODX кеш генерится для каждой страницы принципиально.
В Смарти же, если вы используете один и тот же шаблон (файл) для разных страниц, кеш будет шаблона будет един. То есть если у вас на все про все один-два шаблона, то нагрузка будет ощущаться 1-2 захода после полного очищения кеша, а дальше даже те страницы, на которые еще не заходили, будут работать быстрее.
avatar
Честно сказать сам не понимаю, почему пакет не юзают
Во-первых, я не нашел modSmarty в репозитории modx.com
Во-вторых, к примеру я сразу и не понял как использовать.
avatar
Во-первых, я не нашел modSmarty в репозитории modx.com
Потому что он не modSmarty, а modxSmarty.
Во-вторых, к примеру я сразу и не понял как использовать.
Поправлю на днях. Хотя там видюшка имеется, прям в описании указана.
avatar
Обновил modxSmarty до версии 0.0.4-beta.
Изменения:

1. Дополнил работу тега {field}. Теперь он возвращает но только поля текущего документа, но и значения его TV-полей. Это как когда вы создаете TV-поле tv и вызываете его [[*tv]]

2. Добавился тег {processor}. Это как $modx->runProcessor(), с той лишь разницей, что в параметры можно передавать имя неймспейса (параметр ns), и он автоматически сформирует путь до папки процессоров этого неймспейса.
К примеру, у вас есть папка core/components/mypackage/processors/
Выполняем так: {processor ns=mypackage action=«myaction»}, и будет вызван процессор myaction из вашей папки.
avatar
Делаю интеграцию Twig шаблонизатора. Столкнулся с необходимостью аналогов стандартных сниппетов (getResources, Wayfinder), но выдающие массивы, а не строку.
Есть что-нибудь готовенькое?
avatar
А вот же я писал: community.modx-cms.ru/blog/tips_and_tricks/9966.html
Все нативно будет работать.
То есть чуть-чуть их переделаешь и будешь вот таким методом вызывать.
avatar
А ты как делаешь — создаешь сниппеты или процессоры?
avatar
Все-такие такие вещи должны на процессорах выполняться. Я практически все сейчас на процессорах делаю. Читал этот топик? community.modx-cms.ru/blog/addons/10269.html
Процессоры реально классная штука.
avatar
Процессоры — слишком обобщенная штука. Нужен некий прокси, удобный в вызове, который уже сформирует правильный запрос к процессору и вернет результат.
Можно для этого использовать сниппеты я думаю.
Вобще, слелал черновой вариант с Twig — это просто кайф по сравнению с modx tags.
Не берусь утверждать что это удобней чистого php, но помоему так оно и есть.
avatar
Здорово!
Ждем туториал с демонстрацией основных прелестей.
avatar
Вот, написал уже кое-что. community.modx-cms.ru/blog/dev/10283.html
avatar
Сейчас почитаю
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.