Сразу уточню, что материал рассчитан в основном на тех, что уже использует процессоры, знает что это такое и как их готовить. И вообще этот материал многим может показаться сухим и не интересным. Но кто программирует (Илья, это тебя особенно касается;-)), обязательно надо изучить материал. Поверьте на слово, что это очень мощный инструментарий. Я не раз уже поднимал тему подгрузки файлов-процессоров средствами API MODX. Раньше, когда у нас процессоры были просто php-файлами, нас это вообще не интересовало, мы просто выполняли $modx->runProcessor($action) и все. MODX делал require этого файла и все, возвращал полученный результат. Сейчас же у нас процессоры стали гораздо умнее — их можно расширять другими процесс-классами и т.п. Процессоры сегодня могут содержать очень мощный функционал, и это часто полностью законченные, самостоятельные классы. Так зачем нам писать кучу лишнего кода, когда мы можем использовать уже готовые классы, переопределить их и заставить работать под свои нужды? Рассмотрим стандартный механизм работы процессора (здесь и далее будем рассматривать только «классные» процессоры). Мы выполняем $response =$modx->runProcessor($action,$params, $options); MODX в методе modX::runProcessor определяет путь до файла процессора, и если это класс, то он его инициализирует и возвращает результат выполнения (по сути это всегда результат метода modProcessor::process()). Но что, если мы не хотим получить результат метода processor::process(), а хотим просто получить результат какого-то внутреннего метода класса? То есть нам нужен просто класс? Для этого мы просто подгружаем файл процессора require_once$processor_absolute_path. И тогда нам доступен сам класс процессора. Но в чем здесь проблема? Во-первых, элементарно не удобно. То есть каждый раз нам надо писать актуальный путь до процессора. А если мы его переместили, и вообще в другой пакет? Идти высчитывать кол-во методов dirname(), писать папки и т.п. Во-вторых, отсутствие стандартного метода и единых проверок может даже привести к фатальным ошибкам. В общем, я и с Джейсоном пытался этот вопрос обсуждать, но как-то мы не пришли к какому-то единому знаменателю (я Джейсона пытался убедить в необходимости ввести метод типа modX::loadProcessor()). А вот Марк Mark-H мне сегодня подкинул очевидную идею — использовать $modx->loadClass(); Не могу даже понять почему я раньше до этого не догадался, но его подсказки хватило, чтобы сразу увидеть удобство этого подхода и решение моих проблем. Суть метода xPDO::loadClass заключается в том, что он ищет указанный класс во всех указанных папках подключенных пакетов (если не передан параметр, запрещающий делать это). То есть вы один раз можете выполнить$modx->addPackage($packName,$path); и далее уже выполнять подгрузку файла процессора так: $modx->loadClass($classname, '', false, true); (третий параметр false указывает на то, что не надо игнорировать подключенные пакеты, и надо искать по их папкам, а четвертый параметр true указывает на то, что надо игнорировать класс работы с базой данных (ведь у нас это просто процессор)). Все. Теперь не надо высчитывать пути. Как этот процесс максимально оптимизировать? Каждый раз писать $modx->addPackage() мягко выражаясь — не очень удобно. Потому лучше само собой добавить это в extensionPackages. Но надо учитывать две задачи:

1. Уникальность имен пакетов (то есть нельзя два пакета назвать processors, при этом именно название пакета плюсуется к конечному пути пакета). А ведь нам очень желательно, чтобы процессоры лежали в папке processors, чтобы не рушить стандарты (тот же processor-плагин пакета modxSmarty ищет процессоры именно в папке processors).

2. Возможность указывать несколько пакетов с процессорами. В общем, обычно экстеншены ведут к папке component/model/packageName/. Нам этот путь не подходит, так как противоречит вышеизложенным правилам. Значит делаем два пакета. Один ведет в component/model/packageName/ (он нам нужен для хранения основных классов, в том числе и тех, которые работают с базой данных), а второй в component/processors/packageName/. Через консоль выполняем два запроса: $modx->addExtensionPackage('myPackage', '[[++core_path]]components/myPackage/model/',array( "serviceName" => "myservice", "serviceClass" => "myClass", )); В этом запросе мы не просто добавили свой пакет. Указав serviceName и serviceClass, у нас каждый раз при инициализации MODX будет выполнять еще и$modx->getService($name,$class); То есть у нас всегда в MODX будет свой объект $modx->myservice, который будет инстансом класса myClass.$modx->addExtensionPackage('myProcessors', '[[++core_path]]components/myPackage/processors/'); А вот это уже мы добавили папку для наших процессоров. То есть надо будет создать папку myPackage в [[++core_path]]components/myPackage/processors/, и там создавать наши процессоры. Код нашего сервис-класса будет выглядеть так: class myClass{ public $modx = null;

   function __construct(modX & modx) { this->modx = & $modx; }

   public function loadProcessor(fqn){ return this->modx->loadClass(fqn, '', false, true); } } То есть теперь, чтобы не писать каждый раз эти лишние 3 параметра, можно просто выполнять modx->myservice->loadProcessor($classname); Кстати, не забывайте, что в$classname знак точки — это разделитель директорий, то есть. И вот теперь один небольшой пример: $modx->myservice->loadProcessor('path.myclass'); if($instance = myclass::getInstance(modx, 'myclass' )){ response = $instance->run(); print_r($response->getResponse()); } В данном случае мы могли не только стандартный метод processs выполнить, но и любой другой дозволенный. Так же если вы свои процессоры пишите, и какие-то зависят от других, то теперь не обязательно писать require_once, а можно использовать этот метод, выполняя в начале кода $this->myservice->loadProcessor(); Я сейчас включу этот функционал в обновленную сборку и выложу новый снимок. UPD: В этом методе есть один неприятный момент. xPDO::loadClass не подгрузит два одинаковых по названию файла в разных папках, и не возвращает реальные имена классов процессоров. Переписал этот метод в классе modxsite: gist.github.com/Fi1osof/a87522b0b0ea9e60a2ed/revisions Но это временное решение. Разговаривал с Джейсоном. Нас скоро ждут кардинальные перемены в ядре MODX-а, в том числе и автоподгрузка классов. И вообще он смотрит в сторону удаления метода loadClass. Это все классно, но мне некоторых плюшек не хватает уже сегодня, потому добавляю это в новую сборку (чуть попозже выложу). Основной метод:$modx->modxsite->loadProcessor(), возвращающий реальное название процесор-класса. Обкатывать это будет уже в процессе. UPD2: Обновленная сборка с новым методом $modx->modxsite->loadProcessor(); Так же в сборку были добавлены два пакета: PackMan (для быстрой сборки пакетов их имеющегося на сайте) CMPgenerator (для генерации моделей пакетов из таблиц в базе данных) Если кому-то эти пакеты не известны, изучите в обязательном порядке. UPD3: Данный метод изначально не предполагался как идеальный, а только временное решение, но вот нашелся в нем большой минус, который накладывает серьезные ограничения — область видимость. Традиционно файлы классов подгружаются самим MODX-ом, и в самом файле (за пределами описания класса)$this — это текущая инстанция MODX-а. При вызове же через $modx->modxsite->loadProcessor$this — это $modx->modxsite, который ни в коем случае не является инстанцией MODX. Ввиду этого не получается использовать$this в этих классах. Понятно, что мало кто этот хук вообще использует, но тем не менее. Можно было бы использовать $this->loadProcessor() для подгрузки других процессоров, но это сопровождается теми же проблемами, плюс к этому еще и мешает использовать этот процессор штатными средствами. По этой причине придется все так же использовать require, а$modx->loadProcessor() использовать исключительно для подгрузки только тех процессоров, которые не используют переменную $this. Можно использовать в файлах классов так: if($this instanceof modX){ modxsite = & this->modxsite; } else{ modxsite = & this; } $modxsite->loadProcessor('class'); Но учтите, что хотя если вы про это и забудете, оно будет работать, но по хорошему, лучше этим не злоупотреблять. Только если у вас стабильная выработанная методология. В принципе по мне, так это меньшее зло, чем require_once abs_path;