Сергей Шлоков

Ну да, я видел. Только это опять все через базу.

Проблему деплоя это не решает, потому что вызовы сниппетов и чанков кто-то еще должен прописать в шаблонах или ресурсах — а их как делать статическими?

Я и не писал, что это решает проблему деплоя. Я писал

Таким образом, мы получаем вполне пригодный механизм для улучшения поддержки версионности и деплоя, а также более удобную разработку.

Согласен, с шаблонами и плагинами тоже надо что-то придумывать. Особенно, с плагинами. Разработчики, как правило, в ресурсы не лезут.

Пока я вижу только усложнение работы без явной выгоды. Указывать пути, отказываться от наборов параметеров, echo вместо return — зачем это всё?

Никакого усложнения нет. На самом деле и наборы можно прикрутить. Вместо echo сделать return дело 2 секунд (я считал print лучше, меня переубедили). А уж про пути, конечно, прикольно. Т.е. вот это просто

[[!любойсниппетсpdotools?
	&tpl=`@FILE имяфайла.tpl`
	&tplPath=`путь\к\директории\с\шаблонами`
]]

А у меня путь указать, который кстати, можно и не указывать, это невероятно сложно. Улыбнуло.
Про пакеты я писал, что это тоже решение. Просто кто как привык и какие задачи нужно решить.

pdoTools позволяет загрузить чанки из файлов. Просто можно было бы сделать и загрузку сниппетов из файлов. В продолжении логики и развития функционала pdoTools.

Я это сделал не для поспорить. Мне было интересно поковыряться, экспертное мнение я услышал. Значит отложил в сторону. Пойду лучше с детьми погуляю, раз время свободное выдалось. :)

П.С. А за дефолтными параметрами сниппета MODX все равно в базу лезет. :)

Это MODX-девы (как вы выразились), для которых и сделан вывод через буфер. Не разработчики-авторы MODX, а те программеры, которые решили освоить MODX.
Ретурн так ретурн. В принципе, какая разница. Завтра забудем. :)

Вы не поняли. Без присвоения и возврата во внутренних вызовах, не будет возврата и во внешних.

У меня есть и присвоение и возврат. Вот код для принта

include $this->_scriptFilename;
if (ob_get_length()) {
	$this->_output = ob_get_contents();
}

Я не собираюсь упорствовать. Должен быть, пусть будет. Тем более, что это все равно оказалось никому не нужно :)

Для этого в modScript (расширяемый классом modSnippet) используется костыль ob_start()/ob_get_contents()/ob_end_clean(), и используется он как раз потому что многие именно MODX-разработчики вместо return пишут print/echo в своих сниппетах. Таким образом им просто облегчили жизнь.

Во-первых, не знал, что это костыль.
Во-вторых, они (MODX-разработчики) потому и пишут, что привыкли на php так делать. А тут надо знать про return, именно знать, ибо об это нигде не написано.

Чанки уже давным-давно можно вызывать из файлов через @FILE, так что о них смысла спорить нет.

Не видел такой возможности в парсере, а как надо вызывать?

<?php
return include $path_to_file;

Прикольно. Хорошее решение.

del

Я не большой профи в 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 не нужно знать тонкости и условности этого движка. Как привык так и пиши. Очень часто именно это является камнем в огород со стороны пользователей других движков.

Ок. Спасибо.

Ясно. Моя невнимательность подвела. Картинки слева — это админка, а справа — это фронт.
Еще вопрос, а скрипт ExtJs офис грузит?

Честно говоря, не могу понять связи картинок из админки и вызовом своего контроллера офисом. Видимо возраст сказывается. Василий разъясни специально для меня бестолкового. Офис загружает пользовательский контроллер во фронте (примеры с ключами и продажами), а картинки в админке показывают таблицу предметов как в предыдущей версии без офиса. Т.е. связь интерфейса в админке с офисом от меня ускользнула. А еще эта загадочная фраза Собака друг человека

Вам вовсе не обязательно использовать Ext JS, это просто пример возможностей.

еще больше меня запутала.

Понятно, что хозяин-барин. Но мне кажется это неправильно даже для бесплатного дополнения. А уж для платного вдвойне. Логичнее было бы выложить это отдельным решением для желающих, например, modxExtraOffice. Чтобы остальным 99% не пришлось выпиливать это из своих дополнений. Имхо, разумеется.

А правильно так делать для платного компонента? В самом лучшем случае этим воспользуется 1% разработчиков.
П.С. Это я про Office.

Вот пример подключения и авторизации.

то в $text вместо полностью обработанного содержимого, часть с плейсхолдерами, а часть обработана…

Скорее всего запрос идет через ajax. В этом случае парсятся теги только текущей страницы. Поэтому их нужно парсить самостоятельно.

Если галочку «Оплатить» поставить, то перекинется на сайт системы оплаты. Если галочку не ставить, то оплаты не будет и выведется сообщение, что заявка получена. Т.е. оплата не обязательна. «Optional» так сказать.

Это будет в модуле «Дополнительные элементы» типа такого

Как появится время. Надеюсь, ждать придется не долго. :)

Напишите Марку, пусть выкладывает contentBlock, redactor, simpleCart и остальное.