Пример работы Fenom
Есть решение
Вчера в поддержку магазина обратились с жалобой на медленную работы mSearch2 при небольшом количестве товаров.
При ближайшем рассмотрении выяснилось, что проблема, конечно, не в самом mSearch2, а в чанке, который используется для вывод результатов работы фильтра.
Изначально debugParser показывал такой результат работы.
После двух часов переписывания чанка на Fenom, без дополнительных оптимизаций, результат стал таким:
Вот ссылка на код чанка «до». А вот ссылка на «после».
Конечно, по хорошему из него нужно бы выкинуть и все 12 вызовов сниппетов, перенеся подготовку данных в один &prepareSnippet, но это уже будет дополнительная оптимизация, что в данном случае задачей не ставилось.
Разница и в удобстве написания и в скорости работы очевидна. Надеюсь, это послужит для кого-нибудь примером.
При ближайшем рассмотрении выяснилось, что проблема, конечно, не в самом mSearch2, а в чанке, который используется для вывод результатов работы фильтра.
Изначально debugParser показывал такой результат работы.
После двух часов переписывания чанка на Fenom, без дополнительных оптимизаций, результат стал таким:
Вот ссылка на код чанка «до». А вот ссылка на «после».
Конечно, по хорошему из него нужно бы выкинуть и все 12 вызовов сниппетов, перенеся подготовку данных в один &prepareSnippet, но это уже будет дополнительная оптимизация, что в данном случае задачей не ставилось.
Разница и в удобстве написания и в скорости работы очевидна. Надеюсь, это послужит для кого-нибудь примером.
Комментарии: 55
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Недавно попал мне сайт, страница каталога на котором генерировалась 14-15 секунд. После просмотра чанков, участвующих в формировании элементов каталога, увидел нечто дико страшное — кучи вызовов всего и вся для всех типов товаров, а проверка результата для возврата значений — через сниппет [[IF]]. Причем, почти все там вызывалось некэшированным.
После недолгих раздумий самым простым вариантом стало вникание в Fenom (до того не требовалось в явном виде) и переписывание этого волшебного чанка на нем. К слову сказать, при появлении реальной задачи с феномом удалось подружиться очень быстро.
Итог: время генерации страницы сократилось до 0.8-1.1 сек. Не идеально, но с начальным временем не сравнить. При желании, оптимизировать там еще много чего можно, но требовалось максимально быстро сократить время создания страницы до более-менее адекватных значений.
Код до, после.
А с Fenom, да, красота! Сам не нарадуюсь.
Приведенный код будет практически таким же, согласен.
Начав работу с готовым проектом на смарти, по сравнению со стандартным подходом в MODX, мне не понравилось, что абсолютно все было сделано в шаблонах. Чанки практически не использовались, сниппеты тоже минимально. Получалось, что контроллер и вид смешаны между собой, лишь модель отделена.
Поскольку я пока работал только с одним проектом на смарти, мой комментарий не нужно принимать за истину в последней инстанции. Всегда все зависит от подхода разработчика, а технология лишь инструмент.
Со своей стороны добавлю, что спрашивал только потому что сам феномом не пользовался еще. При этом не вижу в нем какой-то сильной разницы и даже синтаксис сильно схож, потому и поинтересовался, что может вы в силу большего опыта с феномом увидели что-то, чего я не вижу.
Именно за это его и выбрал. Меньше файлов, меньше наворотов — самое то, для начала работы. А если не хватит — можно дальше глядеть уже другие решения: Smarty, Twig, или даже Volt.
ЗЫ: Николай, пару лет назад на встрече в СПб мы прекрасно общались на «ты». Не нужно ко мне на «Вы» обращаться )
Как с этим обстоят дела в смарти — не знаю. Возможно, так же. Николай?
Тем не менее, если говорить о необходимости переписывать все при обновлении уже работающих проектов — в Смарти так же нет необходимости переписывать все. Оставляете все как было, только самые слабые места переписываете на новый лад и все. Я так совсем недавно очередной проект переписывал. Там конечно во многом низкая скорость была из-за неправильной расстановки некешируемых сниппетов, но и в целом проблемы были все по той же причине — слишком много вызовов сниппетов и чанков. Как много? Смотри лог.
По теме — получается, что необходимо провести очень серьезную разницу, чтобы получилось объективное сравнение возможностей и скорости работы. Пока из существенных наглядных отличий в подходах — смарти ориентируется, в первую очередь, на файлы, а феном больше в стандартную структуру MODX вписывается.
При этом, на мелких отвлеченных примерах смарти и феном выглядят практически одинаково. Потому получается, что у каждого есть преимущества, а что выбрать, зависит и от личных предпочтений, и от случая.
Я сравнение точно производить не буду. Николай, может, выделишь как-нибудь время? Даже интересно стало.
ЗЫ: Это не камень в огород :)
Но это он писал еще в 13-ом году. С тех пор картина могла поменяться (и да, нужны тесты), но судя по тестам, смарти не сильно уступал в производительности феному, если не считать холодный запуск, на котором феном явно лучше себя показывает.
Но, вообще, тут речь не о разных шаблонизаторах, тут речь о нормальных шаблонизаторах в сравнении с извращением, которое многие сейчас пишут в чанках MODX.
Поэтому какой-то поддержи Fenom или Smarty от руководства MODX мы не увидим.
Но пока там новости исключительно о MODXCloud, а что и как на нём запускают — без разницы. Просьба не воспринимать серьёзно, обычное ворчание =)
Лично мне (лично мне) уже давно хватает всего, что есть. А чего вдруг не хватит — напишем.
Чтобы научиться чему-то, нужно пробовать и набивать шишки. Я вот тоже далеко не сразу всему научился, да и сейчас каждый день открываю что-то новое.
А потом смотрю на своё старое и думаю «какая ж херня, надо-бы переписать». Это бесконечный процесс.
муд@к иразводила, не буду с ним работать, попробую найти такого же красавчика который сделал мнег@вн@сайт. И ведь это на каждом шагу, достаточно вчитаться в то, что просит клиент и все становится ясно с первых строк. Да взять хоть к примеру строительство дома или ремонт, будь то квартира, авто, абсолютно везде ситуация схожая. Как результат паденение цен на выполнение тех или иных работ, и гора не добросовестных исполнителей чье качество работы, неопытному заказчику, с первого взгляда кажется верхом совершенства, а нормальный человек, потом тратит время на то чтобы разжевать ему все, и разобраться с тем что ему «наклали».Допустим {set $result = $_modx->runSnippet('snippet')}. В таком варианте мы можем получить только строку, поэтому доступен только JSON массив. Однако в таком случае придётся его преобразовать {set $array =$modx->fromJSON($result)}.
Другой способ в сниппете вызвать что-то вроде $modx->setPlaceholders($result,'data_'); Такой способ, в основном и использовался до появления femom.
Подскажите, как корректнее работать выборками, массивами и т.п. в шаблоне
Можно еще вот так:
Но это только для ресурсов.
Только pdoPage это всё равно сделает лучше.
Значит через pdoPage этот массив уже никак не обработать? Не планируешь добавить в pdoPage обработку подобных массивов в будущем? Было бы круто вообще!
Он для оформления, а не для работы с БД.
2. Сниппет делает запрос в БД. По умолчанию это pdoResources, который использует ровно те же методы, что и метод $_modx->getResources().
3. Результат оформляется в чанки тем же pdoResources, который использует Fenom.
4. Вывод на страницу.
Скажи пожалуйста, зачем пытаться сделать всё наоборот? Просто потому, что заняться нечем?
Сниппет:
Содержимое testChunkCommon.tpl:
Результат:
1:
2:
3:
4: some_placeholder
Не могу понять, что я делаю не так. Хелп!
Тестовый сайт:
s3660.h2.modhost.pro/test.html
user: s3660
pass: a0VU4iiGhkmb
1. При вызове чанка из плагина (тестировал на отправке писем, [[+pls]] работает, а феном-плейсхолдеры в любых вариантах — нет)
2. При вызове чанков в некоторых сниппетах. Например в чанках Office или HybridAuth. Феном конструкции работают, а вот плейсхолдеры типа [[+email]], [[+link]], [[+password]] и т.д. не хотят.
Например в чанке tpl.HybridAuth.provider не работают его теги, а теги Fenoma работают без проблем:
Пришлось их оставить не переписывая, а всё что можно было — переписать.