Сергей Шлоков
С нами с 31 января 2013; Место в рейтинге пользователей: #52 часа назад
Финальная версия.
Прошлая давала ошибку при создании нового документа. Добавил проверку есть ли id.
@EVAL
if(! empty( $modx->resource->...
Tv параметр с чекбоксами выборка ресурсов вложенных в дедушку 7
6 часов назад
Постам прошлого, у которых коэф рейтинга -0.1 и ниже, за каждое добавление в избранное и за каждый положительный голос рейтинга, следовало бы повышать...
Еще один эксперимент с рейтингом modx.pro 7
Сегодня в 01:24
смотри информацию о Модификаторы MODX и фильтры phx
Генерация изображения с заданным текстом 6
Вчера в 14:22
Компонент не работает? А чего он тогда висит в магазине?
yClients + MODX - синхронизация CRM 16
19 января 2025, 13:57
Ничего из этого не планируется, если не будет спонсора на это. Компонент написан максимально просто с использованием метода оплаты виджетом, что требо...
[mspPaySelectionWidget] Виджет оплаты PaySelection для miniShop2 3
19 января 2025, 02:46
А сколько таких багов еще осталось по всяким разным компонентам??! Хорошо что добрые люди сообщили :-) А обычно компоненты проверять некому
[SendIt] Обнаружена критическая уязвимость обновитесь до версии 2.1.6 1
17 января 2025, 20:01
Как здорово! А с Ютубом такая штука сработает?
Вставка видео с Rutube с управлением на сайте 5
17 января 2025, 11:28
удалось найти причину? я так понял, плагин работает с minishop2 до версии 2.8.3-pl
[mscDistance] - доставка по городу/району 35
П.С. Все никак не соберусь сделать пакет.
Проверка на ошибки именно такая
А есть ли такой объект можно проверить так
Вот шаблон страницы. Чанки простые, без фильтров и премудростей.
Вызов в различных комбинациях. 5 раз для каждого метода. Показаны средние значения.
Видно, что запросов в базу стало меньше. Но выигрыш небольшой. По крайней мере, на небольших сайтах. При кэшировании разницы вообще нет. Может быть на больших сайтах с вызовом некэшируемых элементов эта разница будет заметнее. Но мне проверить негде.
Вывод. На небольших сайтах результаты в районе погрешности. Преимуществ нет.
Вот такое получилось исследование.
П.С. Оставлю себе для разработки, чтобы не морочится со статическими элементами — каждому нужно прописывать пути в отличие от данного приема. Для простоты поменял логику парсера. Теперь он проверяет, есть ли такой чанк на диске, если есть — грузит, нет — берет из базы. Без всяких подчеркиваний.
Согласен, с шаблонами и плагинами тоже надо что-то придумывать. Особенно, с плагинами. Разработчики, как правило, в ресурсы не лезут.
Никакого усложнения нет. На самом деле и наборы можно прикрутить. Вместо echo сделать return дело 2 секунд (я считал print лучше, меня переубедили). А уж про пути, конечно, прикольно. Т.е. вот это просто
А у меня путь указать, который кстати, можно и не указывать, это невероятно сложно. Улыбнуло.
Про пакеты я писал, что это тоже решение. Просто кто как привык и какие задачи нужно решить.
pdoTools позволяет загрузить чанки из файлов. Просто можно было бы сделать и загрузку сниппетов из файлов. В продолжении логики и развития функционала pdoTools.
Я это сделал не для поспорить. Мне было интересно поковыряться, экспертное мнение я услышал. Значит отложил в сторону. Пойду лучше с детьми погуляю, раз время свободное выдалось. :)
П.С. А за дефолтными параметрами сниппета MODX все равно в базу лезет. :)
Ретурн так ретурн. В принципе, какая разница. Завтра забудем. :)
Я не собираюсь упорствовать. Должен быть, пусть будет. Тем более, что это все равно оказалось никому не нужно :)
Во-вторых, они (MODX-разработчики) потому и пишут, что привыкли на php так делать. А тут надо знать про return, именно знать, ибо об это нигде не написано.
Прикольно. Хорошее решение.
Я не собираюсь отстаивать именно print. Тут как раз я хочу получить экспертное мнение как лучше.
Это как раз и не самое важное. Присвоение идет внутри process(). Отличие лишь в том, что для return надо прописывать а для print нет Просто мне казалось, что для стороннего php программиста сниппет будет выглядеть привычнее с print. Он может написать любой сниппет для MODX менеджера, который сможет его подключить. Я так думаю. Я могу и ошибаться, ибо не профи в этом.
Статические элементы, как мы знаем от Евгения Борисова, на продакшене нужно отключать.
Gitify для меня как высшая математика. Для простых пользователей очень сложно. Установочные пакеты — мейби.
Мне кажется так удобнее и практичнее для разработки. Раз, создал файл. Два, в ресурсе его просто вызываешь как обычно. Все как и было, только файл не в базе, а на диске. Отредактировал, нажал F5 и все сразу обновилось. Используя статические элементы, например, нужно сначала кэш почистить.
По скорости, допустим, сниппеты кэшируются, а чанки нет. За ними нужно лезть в базу.
Согласен, но у меня нет больших и сложных компонентов. А мне кажется, на маленьких данных преимуществ не будет видно. Но попробую ради интереса.
П.С. Даже просто ради эксперимента, мне понравилось.
В MODX перед вызовом сниппета зачитываются его параметры по умолчанию, к ним добавляются параметры вызова и все это передается в сам сниппет. А в данном случае, если сниппета в базе нет, то нет и параметров по умолчанию (хранящихся в поле properties таблицы modx_site_snippets). В данном случае их негде взять. Поэтому, их нужно определять самостоятельно. Но я не вижу в этом проблемы. Многие, в том числе и я, в своих сниппетах проверяют эти параметры. Вот пример. При таком подходе вообще переделывать ничего не нужно.
Тоже и по поводу return. Для php программиста привычнее и логичнее print. А для MODX-программиста — return. На самом деле ничего сложного поменять логику нет. Пара строчек кода. Вопрос именно в подходе — делать как в обычном php или как в MODX.
Мнения разные важны. В данном случае не соглашусь. Это совсем не костыли. Тут работа именно с чистым php по его же стандартам. Т.е. человеку, который знает php и решил разрабатывать на MODX не нужно знать тонкости и условности этого движка. Как привык так и пиши. Очень часто именно это является камнем в огород со стороны пользователей других движков.
Еще вопрос, а скрипт ExtJs офис грузит?
Собака друг человекаеще больше меня запутала.