Привет, Илья! Да, результат addExtensionPackacge() — это как раз запись в эту настройку. Так что и так, и так можно. Надо попробовать добавить в extension_packages строчку и для процессоров. Тогда вообще не придется задумываться, что у меня какие-то левые объекты или процессоры — весь код будет стандартным)))) Не получится здесь одной строчкой обойтись. Задача того, что я делал — возможность подгружать любой процессор из любого пакета, при чем с автоформированием пути. Там слишком много тонкостей. Плюс мой метод возвращает реальное имя класса (сам знаешь, в процессорах используется return 'classname';) Все это никак не укладывается в одну строчку. Еще момент — ты вот своим методом подгрузишь мой процессор, а у меня там используется $this->loadClass(), а у тебя $this будет другим объектом. И все, код разваливается. Здесь любое решение будет костылями (и лучше использовать одни костыли). Решить это можно только тогда, когда Джейсон новый релиз выпустит, учитывающий все эти моменты. Мы вчера с ним основательно пообщались на этот счет. Уверен, он и других людей мнение учитывает, так что будет стандартное решение.

Кстати, есть второй способ прописать пакет, чтобы он подключался при инициализации MODx (по идее это тот же способ, только ручками): заходим в настройки системы, раздел «Система и сервер» и находим там параметр «Пакеты расширений» (extension_packages). Если мы до этого хоть раз запускали addExtensionPackage(), то в его значении уже будут все параметры в JSON — их можно исправить, что-нибудь добавить к ним… Если addExtensionPackage() не запускали, то можно там прописать ручками: [{"Rehab": { "path":"[[++core_path]]components/rehab/model/", "tablePrefix":"modx_rehab_", "serviceName":"Rehab", "serviceClass":"Rehab" } }] (конечно, в одну строчку) Для разных нужных методов, которые используются в разных местах я создал отдельный класс Rehab (в папке пакета) и в нем прописываю функционал. Благодаря этому я в любом месте могу написать $modx->Rehab->phonesToJSON($phones); и массив обработается с нужными проверками, дефолтными значениями. И результат будет каким надо. Если потребуется изменить алгоритм обработки телефонов, я всегда знаю, где искать этот код. А вот пути для процессоров прописывать приходится, конечно… Надо попробовать добавить в extension_packages строчку и для процессоров. Тогда вообще не придется задумываться, что у меня какие-то левые объекты или процессоры — весь код будет стандартным))))

Да. Но дело не только в радости глаза. Уверен, Джейсон сделает все красиво, с неймспейсами и т.п., и будет полная автоподгрузка. На сколько я слышал, у него наработки есть с существенными плюсами по производительности.

Для отступов использовать 4 пробела вместо табуляции. всегда юзал пробелы, где мог) табуляция меня раздражает)) Именовать классы НадоТак а я ещё люблю префиксы-аббревиатуры делать, так сказать группируя по неким общим признакам (напр. имя пакета — нпмВотТак). практически все остальное совпадает со стандартами, наверно работая с modx/xpdo само-собой подстроилось) такой код всегда радует глаз

Вот потому пусть лучше related остается на месте :-)

Чорд, а ведь и правда про винду забыл. А с амазоновским хранилищем не работал никогда — поэтому даже не представляю как это работает…

Ну и я не подумал, что нужно будет разделение по 2 разным папкам. Хотя может быть я не прав. Спишу на нехватку опыта работы в этом фреймворке. core/ — это закрытая папка, там только серверные файлы. assets — это для паблика. Конечно придется две папки юзать.

Надо могу только одно ответить: можете написать новый движок. Только не забудьте про то, что существуют винды всякие и т.п., а так же не только файловые медиасорсы, но и другие, типа облачного Amazon3S и т.п.

На тот момент голова не читала досконально :) Ну и я не подумал, что нужно будет разделение по 2 разным папкам. Хотя может быть я не прав. Спишу на нехватку опыта работы в этом фреймворке. Спасибо, что возились со мной :) Да и еще вопрос, для того, чтобы сделать страницы отличающиеся от главной, тоже насоздавать шаблонов или есть более элегантный путь?