24 авг. 2014 г., 12:40

addPackage vs loadClass vs getService вчём правда брат?

Я часто когда писал под MODX задумывался что из этого мне надо и для чего. Тоесть сам вопрос где и как их использовать. Есть метод $modx->addExtensionPackage($class, $path) но минус этого метода в том что он добавляет в автоматическую загрузку и когда таких классов много это нагружает сайт. И так поехали где правда? Эти методы загружают класс то есть это замена include и require. Первый плюс в том что в случае ошибки мы получим сообщение в MODX error log. Второй плюс в том что если класс уже загружен то ошибки не будет и не надо писать типа if (! class_exists('classname')) {}.

loadClass()

public function loadClass($fqn, $path= '', $ignorePkg= false, $transient= false)
Используем в случае если надо загрузить класс который не использует базу данных
$path = MODX_CORE_PATH . 'components/mycomponent/model/'; $modx->loadClass('myclass.MyClass', $path, true, true);
Последний аргумент true соббщает MODX что наш класс не использует базу данных.

addPackage()

public function addPackage($pkg= '', $path= '', $prefix= null)
Используем если наш класс использует базу данных и имеет сгенерированые map фаилы.
$myclassModelPath = MODX_CORE_PATH . 'components/myclass/model/'; $modx->addPackage('Myclass',$myclassnModelPath , '');
Позволяет нам теперь пользоваться классом например написав так:
$modx->getObject('Myclass');

getService()

public function &getService($name, $class= '', $path= '', $params= array ())
Предзназначен для того чтоб мы легко могли пользоваться функциями класса через альяс:
$myclassModelPath = MODX_CORE_PATH . 'components/myclass/model/'; $modx->getService('myclassAlias', 'myclass.Myclass', $myclassModelPath); //теперь можем использовать альяс для доступа к функциям $modx->myclassAlias->myClassFunction();
Надеюсь вы нашли ответ на этот вопрос для себя раз и навсегда?
На деюсь я в правильном топике написал? )))
Два раза в код обарачивает. Я чтото не так сделал? Я писал так
/code>
в коментариях нормально вроде ))))
$path = MODX_CORE_PATH . 'components/mycomponent/model/'; $modx->loadClass('myclass.MyClass', $path, true, true);
Лучше все это заменить на
$modx->loadClass('myclass.MyClass', '', false, true);
В таком случае нам не надо указывать четкий путь к директории, а третий параметр false указывает на то, что надо искать во всех подключенных пакетах. Но это в случае, если пакет подключен. Твой пример годится в тех случаях, когда пакет не подключен, а класс подключить надо.
Коды не всегда корректно обрабатываются. Типографику подключать надо будет. Это чуть позже.
А вообще здесь какой-то вопрос стоял или нет? Лично я всегда пакеты расширяющие подключаю сразу. Прирост нагрузки ничтожный, а удобств - масса.
То есть addExtensionPackage вполне нормально использовать? Вопрос стоял у меня и я просто исча на них точные ответы написал статью. Как то так ))))
addExtensionPackage очень даже нормально использовать.
Кстати, еще раз перечитал заголовок, и усматриваю довольно серьезное непонимание вещей. Ты сравниваешь вообще разные механизмы. Давай по порядку:
1. xPDO::loadClass() - это метод для подгрузки классов, при чем без разницы каких, xPDO-классов или нет. Рассмотрим на примере: если нам нужно создать новый объект, к примеру $modx->newObject('modUser'), то для этого нам нужен класс modUser, то есть его надо подгрузить. Так вот, xPDO::loadClass($className) этим и занимается, и он автоматически вызывается внутри метода newObject() (как и других похожих методов, типа getObject(), getCollection() и т.п.).
2. xPDO::addPackage() нужен для того, чтобы подключить еще один пакет с классами, то есть еще одну директорию (как правило это директория модуля). Когда пакет подключен, то xPDO::loadClass() ищет во всех подключенных модулях, пока не найдет запрошенный класс (если, как писалось выше, третий параметр не установлен в значение true).
3. xPDO::addExtensionPackage() - это просто автоматическое подключение addPackage(), просто для удобства и автоматизации.
4. xPDO::getService() - вот это совсем другая песня. Для нее справедливо и все то, что перечислено выше (так как тоже используется метод loadClass(), и addPackage()(если надо, само собой еще до вызова метода getService())), но этот метод используется для расширения самого объекта $modx. К примеру, $modx->getService($alias, $class); В случае успеха будет доступен объект $modx->$alias, к примеру $modx->mail или $modx->error. И это совсем не для xPDO-классов.
Так понятней?
Да спасибо так понятней ))
Есть вопрос который поледнее время мучает мне на нравится как робатется с TV через xPDO да и вобще это прокол MODX. Пытаюсь копенсировать MIGXdb или создавать класс который наследует modResource. Потомучто для магаза или ещё чего не удобно по TV сортировать. Попробовал ClassExtender но помойму туповато. Мог бы поделится как решать проблему. Спасибо.
Как по мне то MIGXdb нормальный вариант в целом
Вот здесь писал про наши методы поиска и сортировки.
Хорошо спасибо пора прокачиваться до процессоров )))))
БлагоДарю, Николай! Вы, как всегда выручаете меня. Не знал, как подключить в свой компонент классы стороннего компонента. addPackage пришёл на помощь благодаря Вам.
Всегда пожалуйста :)
Подскажите, пожалуйста, как использовать в сниппете кастомный класс?
Сейчас подключаю через $modx->loadClass, но возникла проблема - если запускать данный сниппет из другого сниппета методом $modx->runSnippet - то кастомный класс не виден и получаю ошибку.
Вы что-то недоговариваете. Если у вас в сниппете это работает, и вы вызываете этот сниппет внутри другого сниппета через $modx->runSnippt() напрямую (а не через другие чанки и т.п.), то все должно нормально работать. Может вы что-то не так вызываете? Или не то пытаетесь вернуть? Приведите коды своих сниппетов (можно частично, только те места, где вызовы происходят).
Сниппет 1 "getF"
$modx->loadClass('myclass', $modx->getOption('assets_path') . 'plugins/g/', true, true); $myObj = new myClass(); $result = $myObj->make($resource_id); return $result; В консоле $resource_id = 1; echo $modx->runSnippet('getF',['resource_id'=>$resource_id]);

Самое интересное что если в 1 сниппете перед return завершить - die( $result ) - то результат в консоле есть.
А какой тип данных возвращает $myObj->make($resource_id); ?
И еще непонятная вещь - не срабатывает только первый вызов $modx->runSnippet('getF',['resource_id'=>$resource_id]); а последующие срабатывают (возвращают значение). миркл
Должен возвращать строку. А возвращает пустую строку.
Странно тогда... Вы точно в результате возвращаете не MODX-тег (типа плейсхолдера или типа того)? Пришлите мне на почту n.lanets@modxclub.ru доступ на сайт, я посмотрю что у вас там не так.
Спасибо за помощь, подготовлю тестовый доступ - напишу вам на почту.

Добавить комментарий