Пример работы Fenom
Вчера в поддержку магазина обратились с жалобой на медленную работы mSearch2 при небольшом количестве товаров.
При ближайшем рассмотрении выяснилось, что проблема, конечно, не в самом mSearch2, а в чанке, который используется для вывод результатов работы фильтра.
Изначально debugParser показывал такой результат работы.
После двух часов переписывания чанка на Fenom, без дополнительных оптимизаций, результат стал таким:
Вот ссылка на код чанка «до». А вот ссылка на «после».
Конечно, по хорошему из него нужно бы выкинуть и все 12 вызовов сниппетов, перенеся подготовку данных в один &prepareSnippet, но это уже будет дополнительная оптимизация, что в данном случае задачей не ставилось.
Разница и в удобстве написания и в скорости работы очевидна. Надеюсь, это послужит для кого-нибудь примером.
При ближайшем рассмотрении выяснилось, что проблема, конечно, не в самом mSearch2, а в чанке, который используется для вывод результатов работы фильтра.
Изначально debugParser показывал такой результат работы.
После двух часов переписывания чанка на Fenom, без дополнительных оптимизаций, результат стал таким:
Вот ссылка на код чанка «до». А вот ссылка на «после».
Конечно, по хорошему из него нужно бы выкинуть и все 12 вызовов сниппетов, перенеся подготовку данных в один &prepareSnippet, но это уже будет дополнительная оптимизация, что в данном случае задачей не ставилось.
Разница и в удобстве написания и в скорости работы очевидна. Надеюсь, это послужит для кого-нибудь примером.
Комментарии: 55
В качестве дополнительного примера
Недавно попал мне сайт, страница каталога на котором генерировалась 14-15 секунд. После просмотра чанков, участвующих в формировании элементов каталога, увидел нечто дико страшное — кучи вызовов всего и вся для всех типов товаров, а проверка результата для возврата значений — через сниппет [[IF]]. Причем, почти все там вызывалось некэшированным.
После недолгих раздумий самым простым вариантом стало вникание в Fenom (до того не требовалось в явном виде) и переписывание этого волшебного чанка на нем. К слову сказать, при появлении реальной задачи с феномом удалось подружиться очень быстро.
Итог: время генерации страницы сократилось до 0.8-1.1 сек. Не идеально, но с начальным временем не сравнить. При желании, оптимизировать там еще много чего можно, но требовалось максимально быстро сократить время создания страницы до более-менее адекватных значений.
Код до, после.
Недавно попал мне сайт, страница каталога на котором генерировалась 14-15 секунд. После просмотра чанков, участвующих в формировании элементов каталога, увидел нечто дико страшное — кучи вызовов всего и вся для всех типов товаров, а проверка результата для возврата значений — через сниппет [[IF]]. Причем, почти все там вызывалось некэшированным.
После недолгих раздумий самым простым вариантом стало вникание в Fenom (до того не требовалось в явном виде) и переписывание этого волшебного чанка на нем. К слову сказать, при появлении реальной задачи с феномом удалось подружиться очень быстро.
Итог: время генерации страницы сократилось до 0.8-1.1 сек. Не идеально, но с начальным временем не сравнить. При желании, оптимизировать там еще много чего можно, но требовалось максимально быстро сократить время создания страницы до более-менее адекватных значений.
Код до, после.
Жуть какая. Уж проще было всё в одном сниппете сделать, чем так.
А с Fenom, да, красота! Сам не нарадуюсь.
А с Fenom, да, красота! Сам не нарадуюсь.
Тот сайт вообще, похоже, делал человек, не знакомый со спецификой MODX.
прирост очевиден, а если тоже на smarty сделать? какой будет результат интересно.
Можно только проверить. Со смарти, из недавнего, я сталкивался на другом проекте, не очень понравился.
Можно поинтересоваться, что именно не понравилось в Смарти? Я не буду отстаивать Смарти, мне просто интересно что там может не понравиться по сравнению с феномом. Если брать за пример приведенный здесь код, то он же будет на Смарти ровно такой же, за исключением необходимости указывать var перед переменными, и вместо $_modx будет писаться привычный $modx.
Николай, очень ожидал твой вопрос. Только забыл добавить в своем предыдущем комментарии «не очень понравился в тот момент».
Приведенный код будет практически таким же, согласен.
Начав работу с готовым проектом на смарти, по сравнению со стандартным подходом в MODX, мне не понравилось, что абсолютно все было сделано в шаблонах. Чанки практически не использовались, сниппеты тоже минимально. Получалось, что контроллер и вид смешаны между собой, лишь модель отделена.
Поскольку я пока работал только с одним проектом на смарти, мой комментарий не нужно принимать за истину в последней инстанции. Всегда все зависит от подхода разработчика, а технология лишь инструмент.
Приведенный код будет практически таким же, согласен.
Начав работу с готовым проектом на смарти, по сравнению со стандартным подходом в MODX, мне не понравилось, что абсолютно все было сделано в шаблонах. Чанки практически не использовались, сниппеты тоже минимально. Получалось, что контроллер и вид смешаны между собой, лишь модель отделена.
Поскольку я пока работал только с одним проектом на смарти, мой комментарий не нужно принимать за истину в последней инстанции. Всегда все зависит от подхода разработчика, а технология лишь инструмент.
Ясно. Спасибо за ответ.
Со своей стороны добавлю, что спрашивал только потому что сам феномом не пользовался еще. При этом не вижу в нем какой-то сильной разницы и даже синтаксис сильно схож, потому и поинтересовался, что может вы в силу большего опыта с феномом увидели что-то, чего я не вижу.
Со своей стороны добавлю, что спрашивал только потому что сам феномом не пользовался еще. При этом не вижу в нем какой-то сильной разницы и даже синтаксис сильно схож, потому и поинтересовался, что может вы в силу большего опыта с феномом увидели что-то, чего я не вижу.
Мне кажется, что Fenom гораздо меньше и проще.
Именно за это его и выбрал. Меньше файлов, меньше наворотов — самое то, для начала работы. А если не хватит — можно дальше глядеть уже другие решения: Smarty, Twig, или даже Volt.
Именно за это его и выбрал. Меньше файлов, меньше наворотов — самое то, для начала работы. А если не хватит — можно дальше глядеть уже другие решения: Smarty, Twig, или даже Volt.
Вот и я, как и писал ниже, если бы со Смарти не задружился значительно раньше, наверняка тоже на феном подсел давно.
Как я написал в первом комментарии, мой опыт работы с феномом начался именно с этого чанка.
ЗЫ: Николай, пару лет назад на встрече в СПб мы прекрасно общались на «ты». Не нужно ко мне на «Вы» обращаться )
ЗЫ: Николай, пару лет назад на встрече в СПб мы прекрасно общались на «ты». Не нужно ко мне на «Вы» обращаться )
Это у меня привычка :) Постараюсь на ты :)
Кстати, что еще сильно подкупает в реализации Василия — возможность использовать феном везде сразу после установки pdoTools. Более того, есть возможность даже совмещать стандартный синтаксис MODX и феном в одном и том же элементе. Это позволяет не полностью на феноме переписывать проект, а изменить сначала наиболее проблемные его места.
Как с этим обстоят дела в смарти — не знаю. Возможно, так же. Николай?
Как с этим обстоят дела в смарти — не знаю. Возможно, так же. Николай?
Честно сказать, чтобы подробней ответить на этот вопрос, мне надо установить феном и погонять его как следует, чтобы получилась какая-то сравнительная таблица функциональности. У меня все-таки идеология чуть шире, хоть и запутанней. К примеру, я не знаю как у Василия обстоят дела со скинами сайтов (Василий, сорри за в третьем лице), а так же что там на счет одновременного подключения нескольких дирректорий шаблонов. Плюс к этому, у меня все-таки обычные MODX-шаблоны заменены на php-шаблоны. Это опять-таки для производительности (хотя последние изменения в системе кеширония MODX-а могут свести эту разницу на нет, опять-таки тестировать надо). Но в целом, выполнение в Смарти парсинг его синтаксиса в чанках так же возможен, тем не менее мы почти полностью отошли от чанков и особо эту функциональность не используем.
Тем не менее, если говорить о необходимости переписывать все при обновлении уже работающих проектов — в Смарти так же нет необходимости переписывать все. Оставляете все как было, только самые слабые места переписываете на новый лад и все. Я так совсем недавно очередной проект переписывал. Там конечно во многом низкая скорость была из-за неправильной расстановки некешируемых сниппетов, но и в целом проблемы были все по той же причине — слишком много вызовов сниппетов и чанков. Как много? Смотри лог.
Тем не менее, если говорить о необходимости переписывать все при обновлении уже работающих проектов — в Смарти так же нет необходимости переписывать все. Оставляете все как было, только самые слабые места переписываете на новый лад и все. Я так совсем недавно очередной проект переписывал. Там конечно во многом низкая скорость была из-за неправильной расстановки некешируемых сниппетов, но и в целом проблемы были все по той же причине — слишком много вызовов сниппетов и чанков. Как много? Смотри лог.
Красивый лог :)
По теме — получается, что необходимо провести очень серьезную разницу, чтобы получилось объективное сравнение возможностей и скорости работы. Пока из существенных наглядных отличий в подходах — смарти ориентируется, в первую очередь, на файлы, а феном больше в стандартную структуру MODX вписывается.
При этом, на мелких отвлеченных примерах смарти и феном выглядят практически одинаково. Потому получается, что у каждого есть преимущества, а что выбрать, зависит и от личных предпочтений, и от случая.
Я сравнение точно производить не буду. Николай, может, выделишь как-нибудь время? Даже интересно стало.
По теме — получается, что необходимо провести очень серьезную разницу, чтобы получилось объективное сравнение возможностей и скорости работы. Пока из существенных наглядных отличий в подходах — смарти ориентируется, в первую очередь, на файлы, а феном больше в стандартную структуру MODX вписывается.
При этом, на мелких отвлеченных примерах смарти и феном выглядят практически одинаково. Потому получается, что у каждого есть преимущества, а что выбрать, зависит и от личных предпочтений, и от случая.
Я сравнение точно производить не буду. Николай, может, выделишь как-нибудь время? Даже интересно стало.
Постараюсь.
Полностью объективного сравнения, кстати, тоже вряд ли стоит ожидать. В зависимости от предпочтений тестируюшего, даже указанное выше отличие может быть плюсом одного и минусом другого. Или наоборот.
ЗЫ: Это не камень в огород :)
ЗЫ: Это не камень в огород :)
Так или иначе, я вынесу это на суд общественности, где каждый сможет высказаться. Но у меня довольно большой богах кейсов как и в каких случаях использовать шаблонизатор, так что посмотрим, сможет ли феном удовлетворить мои потребности :)
Спасибо!
Не за что!
Вот здесь автор фенома тесты проводит со смарти и твигом habrahabr.ru/post/169525/
Но это он писал еще в 13-ом году. С тех пор картина могла поменяться (и да, нужны тесты), но судя по тестам, смарти не сильно уступал в производительности феному, если не считать холодный запуск, на котором феном явно лучше себя показывает.
Но это он писал еще в 13-ом году. С тех пор картина могла поменяться (и да, нужны тесты), но судя по тестам, смарти не сильно уступал в производительности феному, если не считать холодный запуск, на котором феном явно лучше себя показывает.
Ознакомился спасибо, вспомнил что видел эту статью уже, но подзабыл. По его тестам феном впереди. Плюсы конечно очевиды в его пользу, по крайней мере в размере. Сам же я тоже пользуюсь твоим modSmarty меня тоже все устраивает, вещь удобная, спасибо! Пользуюсь давно и почти не использую чанки как таковые, все в файлах. Когднить попробую и fenom, но как то давно уж подсел на смарти.
Ну вот, Смарти освоил, значит и на феном совсем не проблема пересесть :)
Я не знаю Smarty. Так уж получилось, что сразу подружился именно с Fenom.
Но, вообще, тут речь не о разных шаблонизаторах, тут речь о нормальных шаблонизаторах в сравнении с извращением, которое многие сейчас пишут в чанках MODX.
Но, вообще, тут речь не о разных шаблонизаторах, тут речь о нормальных шаблонизаторах в сравнении с извращением, которое многие сейчас пишут в чанках MODX.
Вообще, когда я увидел ту заметку еще в 13-ом году, я Райну писал, мол «посмотри, довольно интересная штука и очень компактная, то есть давайте в MODX как-то это оформите». У него интерес был, но реализации так и не увидел свет. Я же на Смарти с 11-го года еще сижу, и не увидев сильной разницы не стал менять шило на мыло.
Я тоже им это показывал, но для себя понял, что им гораздо интереснее Twig.
Поэтому какой-то поддержи Fenom или Smarty от руководства MODX мы не увидим.
Поэтому какой-то поддержи Fenom или Smarty от руководства MODX мы не увидим.
Нее, думаю дальше простого интереса к Твиг у них не пойдет. Может и выкатят какой-то модуль (хотя вряд ли, Andrew Smith давно уже с ним экспериментировал, но судя по всему это затухло), но в ядро это вряд ли запилят.
Да я не про ядро (туда и раньше ничего не пихали), а просто, мол «зацените, люди!» в блоге или твиттере.
Но пока там новости исключительно о MODXCloud, а что и как на нём запускают — без разницы. Просьба не воспринимать серьёзно, обычное ворчание =)
Лично мне (лично мне) уже давно хватает всего, что есть. А чего вдруг не хватит — напишем.
Но пока там новости исключительно о MODXCloud, а что и как на нём запускают — без разницы. Просьба не воспринимать серьёзно, обычное ворчание =)
Лично мне (лично мне) уже давно хватает всего, что есть. А чего вдруг не хватит — напишем.
А чего вдруг не хватит — напишем.Именно так))
да упырей, которые плодят говно-сайты, позоря имя modx хватает, впрочем как и школьников, которые развиваясь ваяют нечто похожее, за гроши.
Не ругайся.
Чтобы научиться чему-то, нужно пробовать и набивать шишки. Я вот тоже далеко не сразу всему научился, да и сейчас каждый день открываю что-то новое.
А потом смотрю на своё старое и думаю «какая ж херня, надо-бы переписать». Это бесконечный процесс.
Чтобы научиться чему-то, нужно пробовать и набивать шишки. Я вот тоже далеко не сразу всему научился, да и сейчас каждый день открываю что-то новое.
А потом смотрю на своё старое и думаю «какая ж херня, надо-бы переписать». Это бесконечный процесс.
Истина, что ни на есть :)
согласен все учатся на ошибках, нельзя сразу придти к идеальному решению, к сожалению, есть люди, знаком лично, которые не стремятся к совершенству, да и вообще пониманию процессов, как один раз научились так и стряпают думая только о быстром заработке, а не о качестве, или о том как их клиент будет потом работать с тем что эти «чуда» состряпают. В общем стремятся к кол-ву, а не к качеству. И после них на фрилансах появляется море объявлений, мол нужно внести «быстро» нн-е кол-во правок, за все могу заплатить 3 копейки, начинаешь общаться с такими людьми, смотришь что им наворотили, говоришь что быстро внести эти мелкие правки не получиться, а чтоб по нормальному сделать нужно время отчего и цена будет другая. Клиент же начинает думать, мол связался с не пойми с кем навязывает мне не пойми что, за кучу денег, пожалуй этот исполнитель муд@к и разводила, не буду с ним работать, попробую найти такого же красавчика который сделал мне г@вн@ сайт. И ведь это на каждом шагу, достаточно вчитаться в то, что просит клиент и все становится ясно с первых строк. Да взять хоть к примеру строительство дома или ремонт, будь то квартира, авто, абсолютно везде ситуация схожая. Как результат паденение цен на выполнение тех или иных работ, и гора не добросовестных исполнителей чье качество работы, неопытному заказчику, с первого взгляда кажется верхом совершенства, а нормальный человек, потом тратит время на то чтобы разжевать ему все, и разобраться с тем что ему «наклали».
Хуже другое. Такое нередко пишут достаточно хорошие программисты. Вот только они, не зная тонкостей работы MODX, не подозревают, в чем косячат с точки зрения именно MODX.
Подскажите пожалуйста. Как в случае использования фенома корректней всего работать с набором данных, полученных из сниппета. В голову приходит два решения.
Допустим {set $result = $_modx->runSnippet('snippet')}. В таком варианте мы можем получить только строку, поэтому доступен только JSON массив. Однако в таком случае придётся его преобразовать {set $array =$modx->fromJSON($result)}.
Другой способ в сниппете вызвать что-то вроде $modx->setPlaceholders($result,'data_'); Такой способ, в основном и использовался до появления femom.
Подскажите, как корректнее работать выборками, массивами и т.п. в шаблоне
Допустим {set $result = $_modx->runSnippet('snippet')}. В таком варианте мы можем получить только строку, поэтому доступен только JSON массив. Однако в таком случае придётся его преобразовать {set $array =$modx->fromJSON($result)}.
Другой способ в сниппете вызвать что-то вроде $modx->setPlaceholders($result,'data_'); Такой способ, в основном и использовался до появления femom.
Подскажите, как корректнее работать выборками, массивами и т.п. в шаблоне
Сниппеты MODX могут возвращать исключительно строки, так уже повелось. $modx->fromJSON не нужен, Fenom умеет сам это делать:
Можно еще вот так:
{set $result = json_decode($_modx->runSnippet('snippet'), 1)}
Можно еще вот так:
{var $resources = $_modx->getResources(
['published' => 1, 'deleted' => 0],
['sortby' => 'id', 'sortdir' => 'ASC', 'limit' => 50]
)}
{foreach $resources as $resource}
{$_modx->getChunk('@INLINE <p>{$id} {$pagetitle}</p>', $resource)}
{/foreach}
Но это только для ресурсов. Можно еще вот такПрикольно! А постранично никак такое не сделать?
Учитывая, что у Fenom есть доступ к GET — не вижу проблем.
Только pdoPage это всё равно сделает лучше.
Только pdoPage это всё равно сделает лучше.
Я его и имел ввиду. Пардон, что выразился недостаточно полно.
Значит через pdoPage этот массив уже никак не обработать? Не планируешь добавить в pdoPage обработку подобных массивов в будущем? Было бы круто вообще!
Значит через pdoPage этот массив уже никак не обработать? Не планируешь добавить в pdoPage обработку подобных массивов в будущем? Было бы круто вообще!
Сниппеты MODX могут возвращать исключительно строкиНе нужно вешать на шаблонизатор вообще всё, что только в голову приходит.
Он для оформления, а не для работы с БД.
Я имел ввиду массив, полученный методом $_modx->getResources впоследствии передать, как параметр в pdoPage и он уже его съест и обработает постранично. Честно говоря не пойму, при чём тут шаблонизатор. А если даже и «при чём», то метод getResources работает с базой, вроде как. Не?
1. pdoPage не принимает массивы, он вызывает сниппет, которому передаёт offset и limit.
2. Сниппет делает запрос в БД. По умолчанию это pdoResources, который использует ровно те же методы, что и метод $_modx->getResources().
3. Результат оформляется в чанки тем же pdoResources, который использует Fenom.
4. Вывод на страницу.
Скажи пожалуйста, зачем пытаться сделать всё наоборот? Просто потому, что заняться нечем?
2. Сниппет делает запрос в БД. По умолчанию это pdoResources, который использует ровно те же методы, что и метод $_modx->getResources().
3. Результат оформляется в чанки тем же pdoResources, который использует Fenom.
4. Вывод на страницу.
Скажи пожалуйста, зачем пытаться сделать всё наоборот? Просто потому, что заняться нечем?
Наоборот не надо. Мир, Василий! :)
Спасибо за ответ. Получается, что было бы неплохо сделать возможным добавление своих публичных методов. Хотя ответа в виде JSON вполне предостаточно для всех нужд.
P.S. при использовании $modx->setPlaceholder($value,'placeholde'); в шаблоне не видны вновь добавленные плэйсхолдеры в виде {$placeholder}, однако их можно получить путём {$_modx->getPlaceholder('placeholder')}
Они и должны быть получены через специальный метод. Переменные — совсем не то.
А не подскажете ли как в своих сниппетах, использующих чанки для вывода результатов выводит плэйсхолдеры с использованием fenom? {$placeholder} и {$_modx->getPlaceholder['placeholder']} не видны в таких чанках, однако [[+placeholder]] — отображаются нормально.
{$_pls['placeholder']}
Это я тоже пробовал, глухо
Посмотрите отсюда и ниже.
Вызов в шаблоне:
1:
2:
3:
4: some_placeholder
Не могу понять, что я делаю не так. Хелп!
{$_modx->runSnippet('temp')}
Сниппет:<?php
$output = $modx->getChunk('testChunkCommon', array('some_placeholder' => 'some_placeholder'));
return $output;
Содержимое testChunkCommon.tpl:<p>1: {$some_placeholder}</p>
<p>2: {$_pls['some_placeholder']}</p>
<p>3: {$_modx->getPlaceholder('some_placeholder')}</p>
<p>4: [[+some_placeholder]]</p>
Результат:1:
2:
3:
4: some_placeholder
Не могу понять, что я делаю не так. Хелп!
Зато все значения выводятся при вызове сниппета [[!temp]]
Тестовый сайт:
s3660.h2.modhost.pro/test.html
user: s3660
pass: a0VU4iiGhkmb
Тестовый сайт:
s3660.h2.modhost.pro/test.html
user: s3660
pass: a0VU4iiGhkmb
Точно такую же проблему встретил и в других местах:
1. При вызове чанка из плагина (тестировал на отправке писем, [[+pls]] работает, а феном-плейсхолдеры в любых вариантах — нет)
2. При вызове чанков в некоторых сниппетах. Например в чанках Office или HybridAuth. Феном конструкции работают, а вот плейсхолдеры типа [[+email]], [[+link]], [[+password]] и т.д. не хотят.
Например в чанке tpl.HybridAuth.provider не работают его теги, а теги Fenoma работают без проблем:
1. При вызове чанка из плагина (тестировал на отправке писем, [[+pls]] работает, а феном-плейсхолдеры в любых вариантах — нет)
2. При вызове чанков в некоторых сниппетах. Например в чанках Office или HybridAuth. Феном конструкции работают, а вот плейсхолдеры типа [[+email]], [[+link]], [[+password]] и т.д. не хотят.
Например в чанке tpl.HybridAuth.provider не работают его теги, а теги Fenoma работают без проблем:
<!--
<a href="{$login_url}&provider={$title}" class="ha-icon {$provider}" rel="nofollow" title="{$title}">{$title}</a>
-->
{$provider} - не работает
{$_pls['provider']} - не работает
{$_modx->getPlaceholder('provider')} - не работает
{$_modx->config.site_name} - работает
Пришлось их оставить не переписывая, а всё что можно было — переписать. Вот ссылка на код чанка «до». А вот ссылка на «после».Код уже недоступен, к сожалению. Можно его как-то восстановить?
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.