Комментарии 12
И вот опять вот эта ахинея… «Мое прелестное дополнение»…
Это не просто твое прелестное дополнение. Это самое великое из того, что ты сделал — самый великий блеф! Тебе по прежнему удается простачков дурачить тем, что ты офигенный компонент написал и много-много его дорабатываешь. И многие верят (не хватает же мозгов проверить). И главное — сколько уже ты на него из СимплДрима денег вытянул? :-) Ведь тебе оплачивается твое рабочее время.
Ну чтож, давай разберем, что это у тебя за чудо такое неведомое разработано.
Итак, по началу это вообще выдавалось как «альтернатива 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 свои суешь. В итоге ни ты, ни они самого ядра не знают. Могу легко по каждому твоему дополнению проехаться. А что ты там про контексты в своем гибридаусе нес, так я вообще ржал. Только ты ничего не ответил. А жаль…
Это не просто твое прелестное дополнение. Это самое великое из того, что ты сделал — самый великий блеф! Тебе по прежнему удается простачков дурачить тем, что ты офигенный компонент написал и много-много его дорабатываешь. И многие верят (не хватает же мозгов проверить). И главное — сколько уже ты на него из СимплДрима денег вытянул? :-) Ведь тебе оплачивается твое рабочее время.
Ну чтож, давай разберем, что это у тебя за чудо такое неведомое разработано.
Итак, по началу это вообще выдавалось как «альтернатива 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 свои суешь. В итоге ни ты, ни они самого ядра не знают. Могу легко по каждому твоему дополнению проехаться. А что ты там про контексты в своем гибридаусе нес, так я вообще ржал. Только ты ничего не ответил. А жаль…
>>Могу легко по каждому твоему дополнению проехаться.
Николай, думаю Василий по твоим разработкам тоже смог бы проехаться при желании (как и по моим, например). У всех есть свои плюсы и свои минусы. На счет «кто-то кому-то переплачивает» это ты тут очень не красиво приплёл, твоё личное мнение в этом вопросе вряд ли кому-то интересно.
Николай, думаю Василий по твоим разработкам тоже смог бы проехаться при желании (как и по моим, например). У всех есть свои плюсы и свои минусы. На счет «кто-то кому-то переплачивает» это ты тут очень не красиво приплёл, твоё личное мнение в этом вопросе вряд ли кому-то интересно.
Андрей, во-первых, не стоит говорить за других. Не мог бы он проехаться. Потому что там, где у него 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, и правильно его знать и использовать с умом.
Ему прямым текстом говорилось какие есть косяки в коде и как их можно поправить, а он что? «Если бы ты вёл себя иначе, я бы взял твой код и сказал «спасибо»». Да конечно. Его мое поведение интересует, а не качество кода. Странно, меня почему-то интересует качество кода. Ну ничего, позже он втихую как есть скопировал себе этот код. 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, и правильно его знать и использовать с умом.
>>Как видите, в сумме менее двухсот строк. И это и условия всякие, и получение ТВшек…
Так и возможностей у тебя там поменьше. Например, «default_text» ТВ-шек в пролёте. Может ещё чего… фильтрация и сортировка по ТВ (числовым и текстовым) есть?
Так и возможностей у тебя там поменьше. Например, «default_text» ТВ-шек в пролёте. Может ещё чего… фильтрация и сортировка по ТВ (числовым и текстовым) есть?
Андрей, уж ты-то уже опытный программист. Или я тебя переоцениваю?
>> Так и возможностей у тебя там поменьше. Например, «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-я подстановка значения по умолчанию.
Более того, эти операции с джоинами и т.п. будут уже на уровне после подсчета общего кол-ва строк, что экономней в плане нагрузки.
Я случайно опубликовал этот коммент до того, как дописал его полностью, так что еще отвечу на вторую часть вопроса. Карма у меня убитая, так что не могу писать часто. Коммент будет позже.
>> Так и возможностей у тебя там поменьше. Например, «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-я подстановка значения по умолчанию.
Более того, эти операции с джоинами и т.п. будут уже на уровне после подсчета общего кол-ва строк, что экономней в плане нагрузки.
Я случайно опубликовал этот коммент до того, как дописал его полностью, так что еще отвечу на вторую часть вопроса. Карма у меня убитая, так что не могу писать часто. Коммент будет позже.
По поводу фильтрации и сортировки, ты меня вообще сильно поразил… В 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, но ты говорил, что они не дают прироста в производительности, так что их в расчет не бери.
ОК. Покажу как я фильтрую по 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, но ты говорил, что они не дают прироста в производительности, так что их в расчет не бери.
>> в своем расширяющем классе пишем… И вот у тебя уже есть значение по умолчанию.
>>Там есть вот такой метод… Используем его, чтобы дополнить наш запрос.
Так я и не понял в чём ценность твоих процессоров. В том, что там ничего нет, зато всего 200 строчек кода? Для фильтрации видимо надо написать новый процессор ShopmodxWebFilterDataProcessor, который будет экстендить ShopmodxWebGetDataProcessor, который экстендит ShopmodxWebGetlistProcessor, который экстендит modObjectGetListProcessor, который экстендит modObjectProcessor, который экстендит modProcessor (не шутка).
Кстати, вопрос на засыпку: чем отличается сниппет от процессора? На этом я ухожу из этой темы чтобы совсем не засорять офтопом.
>>Там есть вот такой метод… Используем его, чтобы дополнить наш запрос.
Так я и не понял в чём ценность твоих процессоров. В том, что там ничего нет, зато всего 200 строчек кода? Для фильтрации видимо надо написать новый процессор ShopmodxWebFilterDataProcessor, который будет экстендить ShopmodxWebGetDataProcessor, который экстендит ShopmodxWebGetlistProcessor, который экстендит modObjectGetListProcessor, который экстендит modObjectProcessor, который экстендит modProcessor (не шутка).
Кстати, вопрос на засыпку: чем отличается сниппет от процессора? На этом я ухожу из этой темы чтобы совсем не засорять офтопом.
>>У тебя мнение резко поменялось или как?
Там совсем о другом написано. Код я там не трогал, только тестирование результата из-за лживого отзыва, который как оказалось даже на форуме по твоей ссылке кто-то запостил.
Там совсем о другом написано. Код я там не трогал, только тестирование результата из-за лживого отзыва, который как оказалось даже на форуме по твоей ссылке кто-то запостил.
Андрей здесь конкретно решил прикинуться троллем :-)))
Вряд ли ты не понял, скорее прикидываешься (хотя если действительно не понял, что вполне может быть, рас разницы между сниппетом и процессором (функцией и классом) не улавливаешь...).
И хотя это дешевая попытка перевести стрелки с 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
Ткни мне пальцем где там ООП.
Так вот, еще раз, очень простая аналогия: сниппет — это функция, а процессор — это класс, со всеми вытекающими отсюда последствиями.
И скажу последнее (предполагаю, что ты прочитаешь, но скорее всего не ответишь). В моих глазах ты сегодня окончательно упал. Очень глупые и бессмысленные попытки прекрыть лажу бубумкина. Ему нечего сказать, так он хоть молчит, при том. А тебе мало того, что нечего сказать, так это и не твое детище рассматривается. И такие глупейшие стрелки… Печаль. Конечно некрасиво переходить на личности, но говорю это открыто.
Вряд ли ты не понял, скорее прикидываешься (хотя если действительно не понял, что вполне может быть, рас разницы между сниппетом и процессором (функцией и классом) не улавливаешь...).
И хотя это дешевая попытка перевести стрелки с 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
Ткни мне пальцем где там ООП.
Так вот, еще раз, очень простая аналогия: сниппет — это функция, а процессор — это класс, со всеми вытекающими отсюда последствиями.
И скажу последнее (предполагаю, что ты прочитаешь, но скорее всего не ответишь). В моих глазах ты сегодня окончательно упал. Очень глупые и бессмысленные попытки прекрыть лажу бубумкина. Ему нечего сказать, так он хоть молчит, при том. А тебе мало того, что нечего сказать, так это и не твое детище рассматривается. И такие глупейшие стрелки… Печаль. Конечно некрасиво переходить на личности, но говорю это открыто.
Вася, ну что, сказать нечего? Твои индейцы меня конечно заминусуют (ничего другого я не ждал). Но вот думал, может тебе хватит смелости и знаний возразить? Рассказать, что я не прав? Блеснуть знаниями? Не?..
Нет, от тебя не дождаться.
Ну что, продолжай вещать в одностороннем порядке, какое у тебя классное творение. Но ты-то знаешь на самом деле, что это не более чем дешевый пиар. А реальная ценность этого — отрицательная. :-)
Нет, от тебя не дождаться.
Ну что, продолжай вещать в одностороннем порядке, какое у тебя классное творение. Но ты-то знаешь на самом деле, что это не более чем дешевый пиар. А реальная ценность этого — отрицательная. :-)
>>pdoTools и его сниппеты стараются уложить всю работу в 1 запрос к базе данных. Поэтому все указанные ТВ параметры присоединяются через LEFT JOIN.
Вот тут не совсем правда. Если посмотреть в код, то там сначала из БД вытаскиваются имена TV и их значения по умолчанию, а потом с ними делаются джоины. Так что там не один запрос. Да и частенько отдельные запросы получаются быстрее чем один с кучей джоинов, так что это не показатель.
>>Как вам вывод 2012 страниц сайта за полсекунды?
Да, тут надо сравнивать, а не давать пустые цифры, которые зависят от многих факторов. Например, можно было дать цифры xPDO с getCollection, xPDO без getCollection и pdoTools чтобы можно было оценить разницу.
Идея обработки чанков понравилась. Замена Вайфайндеру тоже очень нужная штука, если есть все его возможности. На счет реализации высказываться не буду, т.к. считаю что не место.
Вот тут не совсем правда. Если посмотреть в код, то там сначала из БД вытаскиваются имена TV и их значения по умолчанию, а потом с ними делаются джоины. Так что там не один запрос. Да и частенько отдельные запросы получаются быстрее чем один с кучей джоинов, так что это не показатель.
>>Как вам вывод 2012 страниц сайта за полсекунды?
Да, тут надо сравнивать, а не давать пустые цифры, которые зависят от многих факторов. Например, можно было дать цифры xPDO с getCollection, xPDO без getCollection и pdoTools чтобы можно было оценить разницу.
Идея обработки чанков понравилась. Замена Вайфайндеру тоже очень нужная штука, если есть все его возможности. На счет реализации высказываться не буду, т.к. считаю что не место.
Если посмотреть в код, то там сначала из БД вытаскиваются имена TV и их значения по умолчанию
Я потому и пишу, что «старается». Подготовка есть, куда без нее.
Да, тут надо сравнивать, а не давать пустые цифры
При замене pdoTools::getChunk() на modX::getChunk() время вырастает до 4х секунд. То есть, разница в 8раз.
Если же выбирать такое количество документоа через modX::getCollection(), то скрипт не укладывается в time_limit.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
pdoTools — набор быстрых сниппетов и библиотека