Пользователь
0,0
рейтинг
25 октября 2013 в 21:07

Разработка → pdoTools — набор быстрых сниппетов и библиотека

MODX*

Хочу представить вашему вниманию свою разработку по быстрому выводу контента на сайтах MODX Revolution.

Как известно, эта система целиком построена на собственной ORM под названием xPDO. Она очень упрощает работу, позволяет писать один универсальный код для разных БД, и еще много чего.

К сожалению, она не может похвастаться скоростью вывода (как, наверное, вообще любая ORM), поэтому я попробовал совместить её плюсы с обычным PDO, добавить лучшую работу с чанками и сделать удобную библиотеку для MODX.

Основные особенности:
  • Быстрая работа с БД. Все запросы составляются на xPDO, а выбираются без объектов — на PDO.
  • Предварительная обработка простых плейсхолдеров в чанках. Парсер MODX разбирается только со сложными вызовами.
  • Код чанков можно указывать прямо при вызове сниппета, загружать обычным образом или из статичных файлов.
  • Правильная сортировка, подготовка, обработка и вывод ТВ параметров.
  • Ведение подробного журнала работы сниппета с отметками времени, для отладки.
  • Удобная загрузка классов и множество функций, которые можно применять в своих разработках.
  • В комплекте 8 универсальных сниппетов, которые дают хороший базис разработчику.

Начну с последнего пункта.

8 универсальных сниппетов


Изначально pdoTools был придуман как библиотека для работы других компонентов, например его использует Tickets.

Со временем стало очевидно, что он позволяет с минимальными затратами написать неплохой пакет инструментов, способных заменить стандартные сниппеты MODX.

pdoResources
Сниппет для выборки ресурсов, может заменить getResources. Он поддерживает почти все его возможности, и бладает особенностями:
— подключение других таблиц через разные JOIN
— можно указывать, что именно выбирать из колонок таблиц
— гибкие условия выборки, вплоть до указания чистого SQL

При этом сниппет работает раз в 5 — 10 быстрее.

pdoMenu
Сниппет для генерации меню сайта. Может заменить Wayfinder, поддерживает почти все его параметры и чанки.

Работает быстрее, особенно при первом запуске с холодным кэшем.

pdoPage
Замена для getPage. Генерирует гораздо более правильную пагинацию, и не позволяет пихать некорректные запросы в параметры запроса page и limit.

pdoUsers
Сниппет, который выводит пользовтаелей сайта, умеет фильтровать их по группам и ролям.

pdoCrumbs
Быстрая генерация хлебных крошек, заменяет BreadCrumb.

pdoNeighbors
Вывод соседних документов страниц. То есть: следующий, предыдущий и родитель. Очень удобно использовать для навигации по новостям.

pdoField
Сниппет, получающий любое поле ресурса или его родителя, включая ТВ параметр. Заменяет getResourcesField и UltimateParent.
Умеет выводить «значение по умолчанию».

pdoSitemap
Генерация карты сайта. Очень быстрая замена GoogleSiteMap, разница до 12 раз.



Я специально привел краткое описание сниппетов в начале поста, потому что большинству начинающих пользователей этого будет вполне достаточно, чтобы быстро и комфортно работать в MODX Revoltuion.

На самом деле, при замене стандартных сниппетов аналогами из pdoTools, средний сайт начинает бегать быстрее раза в 2-3. Вы можете заглянуть на страницу документации и подробнее ознакомиться с параметрами и примерами сниппетов здесь.

Прелесть моего дополнения в том, что оно не требует никаких особых манипуляций. Вы просто устанавливаете его из репозитория и можно пользоваться. Если что-то не устраивает, глючит, работает не так, как вы ожидали — старые родные сниппеты по-прежнему с вами, можно использовать их.

А теперь я расскажу, за счет чего pdoTools быстро работает.

Выборка из БД


Для каждой таблицы в MODX существует описание в .map файле. Из коробки система поддерживает 2 базы данных: MySQL и MSSQL, поэтому все запросы в pdoTools генерируются через xPDO.

Начало всегда одинаково:
$q = $modx->newQuery('modResource');
$q->select(array('id', 'pagetitle', 'content'));
$q->sortby('id', 'asc');
$q->limit(10);


А вот дальше мы можем выбрать или объекты:
$resources = $modx->getCollection('modResource', $q);
foreach ($resources as $resource) {
	print_r($resource->toArray());
}


Или массивы:
if ($q->prepare() && $q->stmt->execute()) {
	$resources = $q->stmt->fetchAll(PDO::FETCH_ASSOC);
	foreach ($resources as $resource) {
		print_r($resource);
	}
}


Классический путь MODX Revolution, который используется в компонентах его авторов — выборка через xPDO и дальнейшая работа с объектами. Это удобно, конечно — ведь в модели можно прописать разные преобразования для полей объектов, и проверки.

Но это и очень медленно, к сожалению. Поэтому я использую второй путь — выборку через PDO. Это быстрее в несколько раз.

Грамотная работа с чанками


Чанки, если кто не знает — это такие элементы в дереве MODX, которые содержат только HTML. Они нужны для оформления работы PHP скриптов и отделяют логику от представления в системе.

Вот обычный чанк:
<p>[[+idx]]. <a href="/[[+uri]]">[[+pagetitle]]</a></p>


В чанках могут быть специальные команды для парсера, например:
<p>[[+idx]]. <a href="/[[+uri]]">[[+menutitle:isempty=`[[+pagetitle]]`]]</a></p>


Каждый тег [[+key]] — это будущий объект в парсере MODX. К нему можно указывать разные параметры, фильтры и вообще, программировать таким образом.

Это столько же круто, сколь и медленно.

Поэтому в pdoTools чанки предварительно обрабатываются — всё что можно, заменяется банальным str_replace() из полученнных данных, затем заменяются ссылки [[~[[+id]]]], затем плейсхолдеры лексиконов [[%key]], в вот все, что осталось (10% от изначальной работы) отправляется в парсер MODX.

Конечный результат никак не отличается, но скорость такой обработки в разы выше стандартной.

Пользоваться этим очень просто:
$pdo = $modx->getService('pdoTools');

return $pdo->getChunk('имячанка', array('массив со значениями для подстановки'));


В отиличии от оригинального modX::getChunk(), в pdoTools::getChunk() мы можем пользоваться не только уже подготовленными чанками, но и сразу указывать их с помощью биндинга INLINE:
$pdo = $modx->getService('pdoTools');
$tpl = '@INLINE <p>[[+idx]]. <a href="/[[+uri]]">[[+pagetitle]]</a></p>';
$array = array(
	'idx' => 1,
	'pagetitle' => 'Имя страницы',
	'url' => '/page.html'
);

return $pdo->getChunk($tpl, $array);


Работа с ТВ


pdoTools и его сниппеты стараются уложить всю работу в 1 запрос к базе данных. Поэтому все указанные ТВ параметры присоединяются через LEFT JOIN.

Становится очень удобно фильтровать по ТВ, ведь можно просто указать:
[[!pdoResources?
	&parents=`2`
	&includeTVs=`myTV`
	&where=`{"myTV:>":10}`
]]


И вы получите все ресурсы, из контейнера с id = 2 и значением ТВ myTV больше 10. Можно указывать довольно сложные условия и выборки, поэтому я сделал систему логирования:

Лог работы библиотеки


Почти все сниппеты понимают параметр &shoLog=`1` и выводят менеджеру такую портянку:

По ней очень удобно строить условия и отлаживать запросы в БД.

Использование библиотеки


Библиотека подключается через modX::getService() вот так:
// Если нам нужны только основные функции
$pdo = $modx->getService('pdoTools');
// Если нам нужна работа с БД
$pdo = $modx->getService('pdoFetch');


Первый позволяет быстро работать с чанками:
$pdo->getChunk();
$pdo->parseChunk();


А второй умеет быстро выбирать ресурсы:
$pdo->getObject('modResource', 1);
$pdo->getCollection('modTemplate', array('id:>=' => 2));


Если их скомбинировать, то вот так будет выглядеть весь ваш сайт:
<?php
// Подключем класс
$pdo = $modx->getService('pdoFetch');
// Указываем шаблон
$tpl = '@INLINE <p><a href="/[[+id]]">[[+pagetitle]]</a></p>';
// Выбираем все ресурсы сайта
$resources = $pdo->getCollection('modResource');

$output = '';
foreach ($resources as $resource) {
	// Оформляем
	$output .= $pdo->getChunk($tpl, $resource);
}
// И добавляем лог
$output .= '<pre>'.$pdo->getTime().'</pre>';

return $output;


Как вам вывод 2012 страниц сайта за полсекунды?

Если использовать modX::getChunk(), то будет 4 секунды, вместо 0.5. Это разница только на обработке простого чанков, без условий.

При желании можно включить и проверку прав, указав их в параметр &checkPermissions. Это замедлит работу, но все равно будет быстрее, чем стандартные методы MODX.

Заключение


Это очень краткая информация о возможностях pdoTools.

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

Ссылка на документацию.
Ссылка на репозиторий.
Свежие версии в репозитории Simple Dream.
Стабильные версии в официальном репозитории.
Потестировать без заморочек можно на modx-test.com.
Василий Наумкин @bezumkin
карма
27,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (12)

  • 0
    И вот опять вот эта ахинея… «Мое прелестное дополнение»…

    Это не просто твое прелестное дополнение. Это самое великое из того, что ты сделал — самый великий блеф! Тебе по прежнему удается простачков дурачить тем, что ты офигенный компонент написал и много-много его дорабатываешь. И многие верят (не хватает же мозгов проверить). И главное — сколько уже ты на него из СимплДрима денег вытянул? :-) Ведь тебе оплачивается твое рабочее время.

    Ну чтож, давай разберем, что это у тебя за чудо такое неведомое разработано.

    Итак, по началу это вообще выдавалось как «альтернатива xPDO». Одна из ссылок: it-folio.ru/forum/index.php?topic=663.0
    ШТОА?? Была моя реакция. Какое нафиг без xPDO? Лезем в код: github.com/bezumkin/pdoTools/blob/master/core/components/pdotools/model/pdotools/pdofetch.class.php#L9
    И что там видим?

    protected $query;

    И там еще не мало xPDO по всему компоненту.

    В общем, это никакая не замена xPDO (хорошо хоть давно уже перестал это говорить, понял, что ляпнул не подумавши). Это простой синтаксический сахар, при чем не просто сомнительный, а конкретно ничего под собой не имеющий. Сейчас поясню.

    Следите за руками, что нам предлагается: чтобы у вас все быстрее работало, ставьте мою чудо-тулзу, и у вас все будет супер-быстро работать!
    Так ли это? Лично меня никак не может убедить в этом тот факт, что вместо того, чтобы просто выполнять $modx->newQuery(), мне надо сделать:
    >> Библиотека подключается через modX::getService() вот так:
    // Если нам нужны только основные функции
    $pdo = $modx->getService('pdoTools');
    // Если нам нужна работа с БД
    $pdo = $modx->getService('pdoFetch');

    При этом это не 10 строчек. Это 835 строк здесь: github.com/bezumkin/pdoTools/blob/master/core/components/pdotools/model/pdotools/pdotools.class.php
    и 940 строчек здесь: github.com/bezumkin/pdoTools/blob/master/core/components/pdotools/model/pdotools/pdofetch.class.php

    Но может оно того стоит? Может там что-то есть то, чего нет в ядре? Ведь вон сколько функций сразу выполняется: github.com/bezumkin/pdoTools/blob/master/core/components/pdotools/model/pdotools/pdofetch.class.php#L61
    И это при том, что весь класс xPDOQuery в ядре — 885 строчек: github.com/modxcms/revolution/blob/develop/core/xpdo/om/xpdoquery.class.php

    Нет, не похоже. Новый запрос создать я и без этого могу. $q = $modx->newQquery($className); Колонки указать извлекаемые? Не вопрос — $q->select(array(
    'col1', 'col2', 'col3 as col 4',
    ));
    Таблицу приджоинить? Да хоть $q->leftJoin(), хоть $q->innerJoin(). Как мне будет угодно. Условия добавить??? Так оно всегда там было. $q->where($cond);
    К слову, а в pdoTools условия появились совсем недавно: bezumkin.ru/sections/components/1931/
    Вася, ну ты уже сразу расскажи, о чем умолчал, чего еще не хватает? Там же много еще минусов есть, а? Может ты все-таки расскажешь, что pdoTools не проверяют права доступов, к примеру?

    И вот теперь главное — а нафига все это изучать, когда можно изучать едро? Нафига вот так вот переписывать всю систему?
    Я вот знаю. Потому что xPDO имеет фатальный недостаток ( lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BE%D0%BA ) — его писал не Вася.

    А еще у него 100500 изменений в компонентах, и не забывайте у себя все по гиту сводить…

    Ну быть может у него действительно с производительностью все классно, а? Ведь пишет: >> Как вам вывод 2012 страниц сайта за полсекунды?
    Ну давай сравним твое творение с вот этим небольшим кодом:

    $q = $modx->newQuery('modResource');
    $q->select(array(
    «id»,
    «uri»,
    «pagetitle»,
    «content»,
    ));
    $q->limit(2012);
    $s = $q->prepare();
    $s->execute();
    $i = 1;
    while($row = $s->fetch(PDO::FETCH_ASSOC)){
    $str = "$i";
    $str .= "{$row['pagetitle']}";
    print $str.
    $i++;
    }

    Тоже 2012 документов.
    0,0165 сек. awesomescreenshot.com/0a01vmb228
    При этом 7 мегабайт, а не 18 как у тебя.

    А быть может ты скажешь, что я не умею программировать и наговариваю на тебя? Ну как бы готов поспорить…
    А вот начальство твое в СимплДрим не умеют программировать, поэтому у тебя и получается им ездить по ушам. Поэтому они тебе и платят по прежнему деньги за твои «чудо разработки» :-)

    Но не это плохо. Плохо, что ты начинающих программистов не по тому пути направляешь. Нет, чтобы лучше ядро изучать и их направлять на это, ты им pdoTools свои суешь. В итоге ни ты, ни они самого ядра не знают. Могу легко по каждому твоему дополнению проехаться. А что ты там про контексты в своем гибридаусе нес, так я вообще ржал. Только ты ничего не ответил. А жаль…
    • +1
      >>Могу легко по каждому твоему дополнению проехаться.

      Николай, думаю Василий по твоим разработкам тоже смог бы проехаться при желании (как и по моим, например). У всех есть свои плюсы и свои минусы. На счет «кто-то кому-то переплачивает» это ты тут очень не красиво приплёл, твоё личное мнение в этом вопросе вряд ли кому-то интересно.
      • 0
        Андрей, во-первых, не стоит говорить за других. Не мог бы он проехаться. Потому что там, где у него 1000 строк, у меня 100, 100% на самом MODX.-е. Пойди найди где проехаться. Поэтому и сидит уткнувшись в тряпочку. А вот я бы за свое не молчал. А еще я всегда готов к конструктивному диалогу, ибо меня интересует качество моих разработок. А его здесь интересует только пиар симплдримовского хранилища и еще раз им сказать «смотрите, я не зря свои деньги получаю». Напоминаю: community.modx-cms.ru/blog/questions/9152.html#comment66743
        Ему прямым текстом говорилось какие есть косяки в коде и как их можно поправить, а он что? «Если бы ты вёл себя иначе, я бы взял твой код и сказал «спасибо»». Да конечно. Его мое поведение интересует, а не качество кода. Странно, меня почему-то интересует качество кода. Ну ничего, позже он втихую как есть скопировал себе этот код. github.com/bezumkin/miniShop2/blob/master/core/components/minishop2/model/minishop2/msproduct.class.php#L22
        Только вот спасибо не сказал.
        Про постоянные $modx->getService() после предметных вопросов все, что он нашел ответить, это «Да от балды написал, не переживай. ». и до сих пор пишет везде от балды. И вы, все желающие использовать pdoTools, будете от балды писать :-) Потому что он продолжает все это от балды фигачить.

        По твоим разработкам да, запросто можно пройтись. Ты это наверняка помнишь. community.modx-cms.ru/blog/reklama/10394.html#comment68143
        Но у меня нет к тебе претензий вообще. Потому что ты не выдаешь свои разработки за новые мировые стандарты программирования. А вот здесь ситуация другая. И конечно же каждому решать, что выбирать — изучать ли саму платформу, родное API, или выбирать сторонние решения. Но выбор должен быть. А главное — он должен основываться на чистых и не искаженных фактах. Бубумкин эти факты искажает полностью. Это преступное искажение, потому что он откровенно пиз*ит по поводу самого ядра, и выдает свое решение за самую правильную альтернативу.

        Ты конечно это знаешь, но вкратце еще раз изложу для тех, кто не понимает:

        Кратко:
        xPDO получает конечные объекты в два этапа. 1. Получает данные из БД. 2. Набивает эти данные в конечные объекты. Все это он делает чисто своими средствами.
        Безумкин говорит, что работа xPDO с объектами — это зло (второй этап), поэтому всем говорит «качайте мое детище, оно работает в разы быстрее», и использует первый этап xPDO, то есть формирование SQL-а средствами xPDO и выполняет выборку из БД через PDO (Через которое, собственно, и работает xPDO, так как является его расширением). Но, безумкин не говорит «используйте вот этот первый этап через сам xPDO» (что было бы крайне правильно). Он говорит «качайте мою херню, чтобы использовать этот первый этап».
        Если кто-то хочет ставить себе что-то, чтобы делать то, что итак можно делать — то пусть ставит. Только понимайте, что вы изучаете узкопрофильную вещь. Только решения бубумкина используют эту фигню. Ни один популярный пакет его не использует. И если вам понадобится быстро вникнуть в суть работы других компонентов, то надо будет все-таки еще и сам xPDO изучить. А это будет двойная работа.

        Подробно.
        Чтобы понимать смысл сказанного, стоит посмотреть на один из главных методов получения объекта средствами xPDO — xPDO::load(). github.com/modxcms/revolution/blob/develop/core/xpdo/om/xpdoobject.class.php#L410
        Вот у нас первый этап — получение записей из БД: github.com/modxcms/revolution/blob/develop/core/xpdo/om/xpdoobject.class.php#L425https://github.com/modxcms/revolution/blob/develop/core/xpdo/om/xpdoobject.class.php#L425
        А вот у нас второй этап — получение конечного объекта: github.com/modxcms/revolution/blob/develop/core/xpdo/om/xpdoobject.class.php#L434

        Но это два отдельных метода. Хочешь получить только записи? Не вопрос. Еще один вариант сделать это:
        $q = $modx->newQuery('modResource', 1);
        $q->select(array('id','pagetitle','content'));
        $rows = xPDOObject::_loadRows($modx, 'modResource', $q)->fetchAll(PDO::FETCH_ASSOC);
        print_r($rows);

        Как видим, здесь нет $pdo = $modx->getService('pdoTools'); $pdo = $modx->getService('pdoFetch');
        Здесь нативные методы.

        Наверняка у многих возникают вопросы: а нафига тогда вообще эти объекты? Нафига MODX тормозит и выполняет эти оба этапа и выполняет это тормознутое получение объекта?
        Здесь множество моментов, быстро опишу важнейшие.

        1. Преобразование объектов. В одной таблице могут лежать данные различных классов. К примеру в modx_site_content лежат данные классов, производных от modResource (modDocument — обычный документ, modWebLink — документ-ссылка и прочие, а так же еще может быть куча пользовательских классов). Так вот, в зависимости от указанного в class_key имени класса, будет возвращен инстанс объекта именно этого класса. А там уже и функционал может отличаться, и много чего другого. Хотя записи в БД будут одного типа лежать.
        Довольно подробно об этом написал здесь: modxclub.ru/blog/200.html

        2. Проверка прав доступов. Когда вы просто получаете записи из БД, нет проверки есть ли у пользователя доступ конкретно к этой записи. Когда же выполняется получение объекта, для всех объектов производных от modAccessibleObject будут автоматически проверяться права доступа к этому объекту, где бы вы его не попытались получить. github.com/modxcms/revolution/blob/develop/core/model/modx/modaccessibleobject.class.php#L30

        3. Связи объектов. Тут тоже сразу несколько моментов. Во-первых, быстрый доступ к связанным объектам, к примеру $parent = $document->getOne('Parent');
        Во-вторых, автоматическое удаление связанных зависимых объектов. Удалили пользователя $user->remove(), вслед за ним удалились и профиль пользователя, и участие в группах пользователей и прочие записи, которые не могу существовать без этой записи (если связи прописаны).

        Так что не редко бывают случаи, когда такая вот простая быстрая выборка годится.

        При этом, если вы думаете, что я использую только вот эти тяжелые запросы с конечными объектами, то скажу — это не так. Есть у меня пара классов для этого:
        github.com/Fi1osof/shopModx/blob/master/core/components/shopmodx/processors/web/getlist.class.php
        github.com/Fi1osof/shopModx/blob/master/core/components/shopmodx/processors/web/getdata.class.php
        Как видите, в сумме менее двухсот строк. И это и условия всякие, и получение ТВшек, и сортировка, и дополнительные таблицы и много еще чего. Почему так много, когда так мало строчек кода? Потому что это расширение базовых средств MODX-а, а не написание чего-то своего альтернативного.
        Но я не говорю, что надо использовать только его. Для разных задач нужно использовать наиболее подходящие средства.
        Но я буду говорить — старайтесь использовать средства самого движка. xPDO — это сердце MODX Revolution, и правильно его знать и использовать с умом.
        • +2
          >>Как видите, в сумме менее двухсот строк. И это и условия всякие, и получение ТВшек…

          Так и возможностей у тебя там поменьше. Например, «default_text» ТВ-шек в пролёте. Может ещё чего… фильтрация и сортировка по ТВ (числовым и текстовым) есть?
          • –1
            Андрей, уж ты-то уже опытный программист. Или я тебя переоцениваю?

            >> Так и возможностей у тебя там поменьше. Например, «default_text» ТВ-шек в пролёте.
            Наблюдай функцию setSelection и вот эту строчку: github.com/Fi1osof/shopModx/blob/master/core/components/shopmodx/processors/web/getdata.class.php#L36
            Добавляем одну строчку в селект, и все. Даже если я туда это не прописал (а я стараюсь в ядро не совать все подряд, чтобы не перегружать его), в своем расширяющем классе пишем:
            protected function setSelection(xPDOQuery $c) {
            $c = parent::setSelection($c);

            $c->select(array(
            'tv.default_text',
            ));

            return $c;
            }

            И вот у тебя уже есть значение по умолчанию.

            Или даже так:
            $c->select(array(
            'if(TemplateVarResources.id is not null, TemplateVarResources.value, tv.default_text) as tv_value',
            ));

            Вот тебе еще на уровне SQL-я подстановка значения по умолчанию.

            Более того, эти операции с джоинами и т.п. будут уже на уровне после подсчета общего кол-ва строк, что экономней в плане нагрузки.

            Я случайно опубликовал этот коммент до того, как дописал его полностью, так что еще отвечу на вторую часть вопроса. Карма у меня убитая, так что не могу писать часто. Коммент будет позже.
          • –1
            По поводу фильтрации и сортировки, ты меня вообще сильно поразил… В pdoTools есть какие-то особые средства по сортировке и фильтру полей? Прям вот реально особые? Может замена PDO? Или вообще замена SQL???

            ОК. Покажу как я фильтрую по TV.

            Мои процессоры — расширение базовых процессоров самого MODX-а. Там есть вот такой метод: github.com/modxcms/revolution/blob/develop/core/model/modx/modprocessor.class.php#L571

            Используем его, чтобы дополнить наш запрос.

            public function prepareQueryBeforeCount(xPDOQuery $c) {
            $c = parent::prepareQueryBeforeCount($c);
            $c->innerJoin('modTemplateVarResource', 'my_tv', «my_tv.id={$some_tv_id} AND my_tv.contentid = {$this.classKey}.id AND my_tv.value={$some_value}»);
            return $c;
            }

            Все варианты условий не буду здесь приводить.

            С сортировкой так же нет особых проблем. Чаще всего это через стандартный параметр sort.

            public function initialize(){
            $this->setDefaultProperties(array(
            «sort» => «CONVERT( tv_value, unsigned )»,
            «sortdir» => «DESC»,
            ));
            return parent::initialize();
            }

            Но «особых проблем» не зря сказал. Недочет действительно есть. Этот момент наследственно тянется с базового процессора, где сортировка всегда рассчитывается только на одну колонку. Так что надо будет еще добраться и ввести еще один метод, в котором можно было бы корректно указывать любые условия сортировки. Сейчас из-за того, что используется клонирование объекта запроса, приходится подумать как это сделать покрасивее. Пока что я методы этих сортировок использую в своих пользовательских процессорах, не включая их в основной процессор. Ищу оптимальное решение.

            В общем, говорить, что там нет чего-то важного — крайне не правильно. Все необходимое есть. Там нет ВСЕГО СРАЗУ. Но все сразу и не нужно. Во-первых, нагрузка лишняя. Во-вторых, сложнее в освоении.

            Кстати, ты и сам не так давно поднял вопрос на счет преувеличений по производительности этих тулзов: wdevblog.net.ru/blog/kto-byistree.html
            У тебя мнение резко поменялось или как?

            У меня вот проблем с производительностью нет. Вот, пощелкай: hamster-fox.ru/
            5000+ товаров. И скажу точно: там нет pdoTools. Там все на самом MODX крутится. Ну еще, конечно же мои phpTemplates+modxSmarty, но ты говорил, что они не дают прироста в производительности, так что их в расчет не бери.
            • +2
              >> в своем расширяющем классе пишем… И вот у тебя уже есть значение по умолчанию.

              >>Там есть вот такой метод… Используем его, чтобы дополнить наш запрос.

              Так я и не понял в чём ценность твоих процессоров. В том, что там ничего нет, зато всего 200 строчек кода? Для фильтрации видимо надо написать новый процессор ShopmodxWebFilterDataProcessor, который будет экстендить ShopmodxWebGetDataProcessor, который экстендит ShopmodxWebGetlistProcessor, который экстендит modObjectGetListProcessor, который экстендит modObjectProcessor, который экстендит modProcessor (не шутка).

              Кстати, вопрос на засыпку: чем отличается сниппет от процессора? На этом я ухожу из этой темы чтобы совсем не засорять офтопом.
              • 0
                >>У тебя мнение резко поменялось или как?

                Там совсем о другом написано. Код я там не трогал, только тестирование результата из-за лживого отзыва, который как оказалось даже на форуме по твоей ссылке кто-то запостил.
              • –1
                Андрей здесь конкретно решил прикинуться троллем :-)))

                Вряд ли ты не понял, скорее прикидываешься (хотя если действительно не понял, что вполне может быть, рас разницы между сниппетом и процессором (функцией и классом) не улавливаешь...).

                И хотя это дешевая попытка перевести стрелки с awesome pdoTools на мои типа неполноценные процессоры, я все же отвечу.

                Посмотри еще раз вот на эту сборку магазина: habrahabr.ru/post/195090/
                Она полностью работает на этих и базовых процессорах. И да, там надо расширять процессоры. Вот только не говори, что твой шопкипер ставишь, и получаешь сразу готовый магазин и больше вообще на сайте ничего делать не надо. Но в отличие от сниппетов, процессоры возвращают данные в массиве (как вариант), а значит эти данные можно много где использовать, и на уровне шаблонов конечный вывод преобразовать всячески, что исключает необходимость плодить почти копии сниппетов.

                Посмотрим детальней. Вот основной процессор вся всего сайта, для выборки любых документов: github.com/Fi1osof/ShopModxBox/blob/master/core/components/modxsite/processors/web/getdata.class.php
                С проверкой опубликованности, сортировкой, формированием ссылок для modWebLink и т.п., в нем 180 строк. Еще 200 строк — класс обрезки текста.

                Вот процессор выборки товаров: github.com/Fi1osof/ShopModxBox/blob/master/core/components/modxsite/processors/web/catalog/products/getdata.class.php
                Здесь сразу и цены, и категории, и картинки, и фильтр по новинкам. Мало функционала? На 95% задач хватает. 80 строчек.

                Процессор поиска товаров по категориям? Не вопрос. github.com/Fi1osof/ShopModxBox/blob/master/core/components/modxsite/processors/web/catalog/category/products/getdata.class.php
                50 строчек.

                Поковыряй всю папку этих процессоров: github.com/Fi1osof/ShopModxBox/tree/master/core/components/modxsite/processors/web
                Там их не много. И на этом весь каталог работает. 4 процессора основных (валюты и метрику брать нет смысла в расчет).

                Так что про недостаток функционала не надо заливать. Качай сборку готового магазина с корзиной, оплатой, социалками, личным кабинетом и т.п., и можешь убедиться — там нет pdoTools, getProducts и т.п. И это не тысячи строк, и не десятки тысяч строк. Один только сниппет ms_products из родного минишопа, написанный максимально оптимально создателем pdoTools весит 150 строчек: github.com/bezumkin/miniShop2/blob/master/core/components/minishop2/elements/snippets/snippet.ms_products.php
                А еще в довесок небольшое кол-во чакнов-шаблончиков: github.com/bezumkin/miniShop2/tree/master/core/components/minishop2/elements/chunks
                Так что похвастаться экономией строк с использованием pdoTools тоже не получается.

                В общем, твои выпады здесь вообще не проходят. Но ты можешь выложить снимок своей демки demo-revo.modx-shopkeeper.ru/ и похвастаться. Рассказать как там все клева. Я поставлю, посмотрю, и может действительно мне придется посыпать свою голову пеплом, а?

                А вот ты заапросто можешь установить сборку ShopModxBox и посмотреть что и как там устроено. Вот такая, к примеру, картина с чанками и сниппетами: www.diigo.com/item/image/3q9lh/xj8d

                Ну и напоследок по поводу разницы между сниппетом и процессором: ты уже поднимал этот вопрос: community.modx-cms.ru/blog/tips_and_tricks/10350.html#comment67907
                Тогда ты ляпнул не подумавши, и так мне и не ответил на удивленный вопрос — где это ты нашел ООП в сниппетах?
                Еще раз, если ты про это: github.com/splittingred/Wayfinder/blob/develop/core/components/wayfinder/wayfinder.class.php
                то это не сниппет. Это отдельный класс.
                Вот сниппет: github.com/splittingred/Wayfinder/blob/develop/core/components/wayfinder/wayfinder.snippet.php
                Ткни мне пальцем где там ООП.

                Так вот, еще раз, очень простая аналогия: сниппет — это функция, а процессор — это класс, со всеми вытекающими отсюда последствиями.

                И скажу последнее (предполагаю, что ты прочитаешь, но скорее всего не ответишь). В моих глазах ты сегодня окончательно упал. Очень глупые и бессмысленные попытки прекрыть лажу бубумкина. Ему нечего сказать, так он хоть молчит, при том. А тебе мало того, что нечего сказать, так это и не твое детище рассматривается. И такие глупейшие стрелки… Печаль. Конечно некрасиво переходить на личности, но говорю это открыто.
  • 0
    Вася, ну что, сказать нечего? Твои индейцы меня конечно заминусуют (ничего другого я не ждал). Но вот думал, может тебе хватит смелости и знаний возразить? Рассказать, что я не прав? Блеснуть знаниями? Не?..
    Нет, от тебя не дождаться.
    Ну что, продолжай вещать в одностороннем порядке, какое у тебя классное творение. Но ты-то знаешь на самом деле, что это не более чем дешевый пиар. А реальная ценность этого — отрицательная. :-)
  • 0
    >>pdoTools и его сниппеты стараются уложить всю работу в 1 запрос к базе данных. Поэтому все указанные ТВ параметры присоединяются через LEFT JOIN.

    Вот тут не совсем правда. Если посмотреть в код, то там сначала из БД вытаскиваются имена TV и их значения по умолчанию, а потом с ними делаются джоины. Так что там не один запрос. Да и частенько отдельные запросы получаются быстрее чем один с кучей джоинов, так что это не показатель.

    >>Как вам вывод 2012 страниц сайта за полсекунды?

    Да, тут надо сравнивать, а не давать пустые цифры, которые зависят от многих факторов. Например, можно было дать цифры xPDO с getCollection, xPDO без getCollection и pdoTools чтобы можно было оценить разницу.

    Идея обработки чанков понравилась. Замена Вайфайндеру тоже очень нужная штука, если есть все его возможности. На счет реализации высказываться не буду, т.к. считаю что не место.
    • 0
      Если посмотреть в код, то там сначала из БД вытаскиваются имена TV и их значения по умолчанию

      Я потому и пишу, что «старается». Подготовка есть, куда без нее.

      Да, тут надо сравнивать, а не давать пустые цифры

      При замене pdoTools::getChunk() на modX::getChunk() время вырастает до 4х секунд. То есть, разница в 8раз.

      Если же выбирать такое количество документоа через modX::getCollection(), то скрипт не укладывается в time_limit.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.