Чанк грузится или из базы или из кэша. Когда он загрузится, идет проверка. Если чанк статичный, то сравнивается содержимое файла и чанка и если они не равны, то содержимое файла сохраняется в чанк в следующей строчке.
Провел небольшой тест на своем сайте (на локалке). Ресурсов меньше 100. Тренировался только на чанках. Время вызова сниппета pdoMenu в чанке [[$main_menu]] отличается на 0.02 сек. Поэтому я его учитывать не стал.
Вот шаблон страницы. Чанки простые, без фильтров и премудростей.
Вызов в различных комбинациях. 5 раз для каждого метода. Показаны средние значения.
--------------------------------------------------------------
ВЫЗОВ КЭШИРУЕМЫХ ЧАНКОВ
--------------------------------------------------------------
// Чанки MODX из базы
Первый запуск Второй (из кэша)
Время: 0.74 | 0.21
Запросы: 63 | 10
// Чанки с диска
Первый запуск Второй (из кэша)
Время: 0.66 | 0.21
Запросы: 58 | 10
--------------------------------------------------------------
ВЫЗОВ НЕКЭШИРУЕМЫХ ЧАНКОВ
--------------------------------------------------------------
// Чанки MODX из базы
Первый запуск Второй
Время: 0.74 | 0.32
Запросы: 63 | 12
// Чанки с диска
Первый запуск Второй
Время: 0.66 | 0.27
Запросы: 58 | 12
--------------------------------------------------------------
ВЫЗОВ НЕКЭШИРУЕМЫХ СТАТИЧЕСКИХ ЧАНКОВ
--------------------------------------------------------------
// Статические чанки MODX
Первый запуск Второй
Время: 0.77 | 0.32
Запросы: 65 | 12
// Чанки с диска
Первый запуск Второй
Время: 0.66 | 0.27
Запросы: 58 | 12
Видно, что запросов в базу стало меньше. Но выигрыш небольшой. По крайней мере, на небольших сайтах. При кэшировании разницы вообще нет. Может быть на больших сайтах с вызовом некэшируемых элементов эта разница будет заметнее. Но мне проверить негде.
Вывод. На небольших сайтах результаты в районе погрешности. Преимуществ нет.
Вот такое получилось исследование.
П.С. Оставлю себе для разработки, чтобы не морочится со статическими элементами — каждому нужно прописывать пути в отличие от данного приема. Для простоты поменял логику парсера. Теперь он проверяет, есть ли такой чанк на диске, если есть — грузит, нет — берет из базы. Без всяких подчеркиваний.
Проблему деплоя это не решает, потому что вызовы сниппетов и чанков кто-то еще должен прописать в шаблонах или ресурсах — а их как делать статическими?
Я и не писал, что это решает проблему деплоя. Я писал
Таким образом, мы получаем вполне пригодный механизм для улучшения поддержки версионности и деплоя, а также более удобную разработку.
Согласен, с шаблонами и плагинами тоже надо что-то придумывать. Особенно, с плагинами. Разработчики, как правило, в ресурсы не лезут.
Пока я вижу только усложнение работы без явной выгоды. Указывать пути, отказываться от наборов параметеров, echo вместо return — зачем это всё?
Никакого усложнения нет. На самом деле и наборы можно прикрутить. Вместо echo сделать return дело 2 секунд (я считал print лучше, меня переубедили). А уж про пути, конечно, прикольно. Т.е. вот это просто
А у меня путь указать, который кстати, можно и не указывать, это невероятно сложно. Улыбнуло.
Про пакеты я писал, что это тоже решение. Просто кто как привык и какие задачи нужно решить.
pdoTools позволяет загрузить чанки из файлов. Просто можно было бы сделать и загрузку сниппетов из файлов. В продолжении логики и развития функционала pdoTools.
Я это сделал не для поспорить. Мне было интересно поковыряться, экспертное мнение я услышал. Значит отложил в сторону. Пойду лучше с детьми погуляю, раз время свободное выдалось. :)
П.С. А за дефолтными параметрами сниппета MODX все равно в базу лезет. :)
Это MODX-девы (как вы выразились), для которых и сделан вывод через буфер. Не разработчики-авторы MODX, а те программеры, которые решили освоить MODX.
Ретурн так ретурн. В принципе, какая разница. Завтра забудем. :)
Для этого в modScript (расширяемый классом modSnippet) используется костыль ob_start()/ob_get_contents()/ob_end_clean(), и используется он как раз потому что многие именно MODX-разработчики вместо return пишут print/echo в своих сниппетах. Таким образом им просто облегчили жизнь.
Во-первых, не знал, что это костыль.
Во-вторых, они (MODX-разработчики) потому и пишут, что привыкли на php так делать. А тут надо знать про return, именно знать, ибо об это нигде не написано.
Я не большой профи в php. Просто мне кажется, что раз php файлы лежат отдельно, они не должны включать логику MODX. А пользователи yui, laravel тоже в инклюдах прописывают return?
Я не собираюсь отстаивать именно print. Тут как раз я хочу получить экспертное мнение как лучше.
Самое важное: $output= $snippet->process($params);
Это как раз и не самое важное. Присвоение идет внутри process(). Отличие лишь в том, что для return надо прописывать
$includeResult= include $this->_scriptFilename;
а для print нет
include $this->_scriptFilename;
Просто мне казалось, что для стороннего php программиста сниппет будет выглядеть привычнее с print. Он может написать любой сниппет для MODX менеджера, который сможет его подключить. Я так думаю. Я могу и ошибаться, ибо не профи в этом.
Со времен Evolution в любом сниппете можно сделать
include 'file.php';
В сниппете да, а в ресурсе, чанке, шаблоне? И без фильтров и других примочек MODX.
Есть статические элементы, есть Gitify, есть установочные пакеты
Статические элементы, как мы знаем от Евгения Борисова, на продакшене нужно отключать.
Gitify для меня как высшая математика. Для простых пользователей очень сложно. Установочные пакеты — мейби.
Короче, без серьёзного профита в удобстве или скорости это просто любопытный эксперимент, не более.
Мне кажется так удобнее и практичнее для разработки. Раз, создал файл. Два, в ресурсе его просто вызываешь как обычно. Все как и было, только файл не в базе, а на диске. Отредактировал, нажал F5 и все сразу обновилось. Используя статические элементы, например, нужно сначала кэш почистить.
По скорости, допустим, сниппеты кэшируются, а чанки нет. За ними нужно лезть в базу.
С этого нужно было начинать. Без серьёзного улучшения производительности говорить не о чем.
Согласен, но у меня нет больших и сложных компонентов. А мне кажется, на маленьких данных преимуществ не будет видно. Но попробую ради интереса.
П.С. Даже просто ради эксперимента, мне понравилось.
А нельзя всё привести к общему стандарту MODX? Ведь это лишняя проблема помнить о том, что там так, а тут не так.
Это проблема для людей, которые учили php через MODX. Как и я собственно, начал учить php разбираясь со снипетами. Но у php свои правила и стандарты.
В MODX перед вызовом сниппета зачитываются его параметры по умолчанию, к ним добавляются параметры вызова и все это передается в сам сниппет. А в данном случае, если сниппета в базе нет, то нет и параметров по умолчанию (хранящихся в поле properties таблицы modx_site_snippets). В данном случае их негде взять. Поэтому, их нужно определять самостоятельно. Но я не вижу в этом проблемы. Многие, в том числе и я, в своих сниппетах проверяют эти параметры. Вот пример. При таком подходе вообще переделывать ничего не нужно.
Тоже и по поводу return. Для php программиста привычнее и логичнее print. А для MODX-программиста — return. На самом деле ничего сложного поменять логику нет. Пара строчек кода. Вопрос именно в подходе — делать как в обычном php или как в MODX.
Если честно, мне это решение кажется каким-то костыльным, чтоли.
Мнения разные важны. В данном случае не соглашусь. Это совсем не костыли. Тут работа именно с чистым php по его же стандартам. Т.е. человеку, который знает php и решил разрабатывать на MODX не нужно знать тонкости и условности этого движка. Как привык так и пиши. Очень часто именно это является камнем в огород со стороны пользователей других движков.
Честно говоря, не могу понять связи картинок из админки и вызовом своего контроллера офисом. Видимо возраст сказывается. Василий разъясни специально для меня бестолкового. Офис загружает пользовательский контроллер во фронте (примеры с ключами и продажами), а картинки в админке показывают таблицу предметов как в предыдущей версии без офиса. Т.е. связь интерфейса в админке с офисом от меня ускользнула. А еще эта загадочная фраза Собака друг человека
Вам вовсе не обязательно использовать Ext JS, это просто пример возможностей.
Понятно, что хозяин-барин. Но мне кажется это неправильно даже для бесплатного дополнения. А уж для платного вдвойне. Логичнее было бы выложить это отдельным решением для желающих, например, modxExtraOffice. Чтобы остальным 99% не пришлось выпиливать это из своих дополнений. Имхо, разумеется.
Проверка на ошибки именно такая
А есть ли такой объект можно проверить так
Вот шаблон страницы. Чанки простые, без фильтров и премудростей.
Вызов в различных комбинациях. 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 офис грузит?
Собака друг человекаеще больше меня запутала.
П.С. Это я про Office.