Valentin Kuzmenko 21 октября 2014 1 29
Николай, позволь спросить тебя, на счёт процессоров, насколько они будут работать быстрее и эффективней чем стандартный getResources или похожий getProducts? Большинство тех кто создаёт своё детище естественно его и продвигает, и возникает вопрос, а насколько эффективней данный продукт, чем остальные похожие по своей работе пакеты, сниппеты, прагины. Я читал некоторые твои статьи(топики) и там ты никого не упрашиваешь пользоваться твоим продуктом, а порой даже отговариваешь, так как что бы работать со многими твоими продуктами, необходимо не мало приложить и своих усилий + приложить к этому голову с ясным умом, не всем под силу использовать твои решения. Есть ли у тебя некое сравнение, может ты когда то делал такие тесты как, скорость, удобство в использование, гибкость в настраивании и т.д. если есть такие характеристики то хотелось бы увидеть.
29 комментариев
vanchelo1
vanchelo 21 октября 2014г в 19:29 #
Гибкость процессоров только в наследовании и том что он возвращает любой тип данных, а сниппет без танцев с бубнов всегда возвращает строку. А так по сути процессор это просто классы со стандартизированной в рамках MODX определенной логикой, в MODX их почему-то назвали именно так)
Fi1osof1
Fi1osof 21 октября 2014г в 20:33 #
Ваня уже в целом ответил. Да, главные минусы сниппетов (а getResources (здесь и далее подразумевается и getProducts, так как getProducts - это модифицированный getResources) - это сниппеты), что они возвращают только строковые результаты и что их нельзя расширять и т.п.
Плюс к этому я бы еще добавил кое что:
1. Рост кеша страницы. Сниппет и надо вызывать как сниппет, хоть он будет тегом прописан (и его потом MODX-парсер вызовет), хоть вы сами через $modx->runSnippet() вызовите. И прикол в том, что в любом случае кеш кода сниппета будет сложен в кеш страницы. В общих чертах про это писал здесь. В итоге даже при заходе на полностью кешированную страницу, даже если ничего выполняться не будет, инициируется довольно большой кеш-файл, который в итоге набивается в большой массив. А это потеря и времени, и ресурсов (в том числе памяти).
2. getResources оперирует объектами, в то время как getdata-процессор только данными. В итоге разница в скорости и ресурсах в разы. Правда здесь минус getdata-процессора - не учитываются права на запрашиваемые данные (то есть если делать выборку документов из раздела, в котором часть документов - привилегированные, getResources выдаст только доступные документы, а getdata-процессор все документы). Но это тоже лечится. Здесь же выполняются выборки с учетом прав.
Есть еще всякие мелочи, но не буду глубоко копаться.
Tramp13571
Tramp1357 21 октября 2014г в 20:52 #
По своему опыту могу сказать: стоит попробовать процессоры раз, и про сниппеты забудешь :)
V
Valentin Kuzmenko 22 октября 2014г в 05:26 #
провёл для себя эксперимент выявить каким способом быстрее достать данные, например достать id=185 и его tv параметр price0
привожу листинги кодов
1)
$begin_time = time() - 1272000000 + floatval(microtime());
$q1 = $modx->newQuery('modTemplateVarResource');
$q1->where(array('tmplvarid' => '19'));
$q1->select(array('modTemplateVarResource.*'));
$q1->limit(1000);
$q1->prepare();
$q1->stmt->execute();
$tvres = $q1->stmt->fetchAll(PDO::FETCH_ASSOC);
//print_r($tvres);
//-------resources------------
$q = $modx->newQuery('modResource');
$q->where(array(
'context_key' => 'web'
));
$q->select(array(
'modResource.*'
));
$q->limit(1000);
$q->prepare();
$q->stmt->execute();
$result = $q->stmt->fetchAll(PDO::FETCH_ASSOC);
$id = 185;//ресурс который ищем
foreach($result as $res){
if($res[id] == $id ){
foreach($tvres as $tv){
if($tv[contentid] == $id){
echo $res[pagetitle] . "\n";
echo $tv[value] . "\n";
}
}
}
}
$end_time = time() - 1272000000 + floatval(microtime()) - $begin_time;
echo $end_time;

время потраченое 0.055360972881317
второй листинг
2)
$begin_time = time() - 1272000000 + floatval(microtime());
$outHtmlAll='';
$modx->setLogLevel(3);
$namespace = 'shopmodx';
if(!$response = $modx->runProcessor('web/getdata',
array( "limit" => 1000
// Параметры
), array(
'processors_path' => $modx->getObject('modNamespace', $namespace)->getCorePath().'processors/',
))){
print "Не удалось выполнить процессор";
return;
}
$res0 = $response->getResponse();
//print_r($res0);
$id = 185;//ресурс который ищем
echo $res0[object][$id][pagetitle]. "\n";
echo $res0[object][$id][tvs][price0][value]. "\n";
$end_time = time() - 1272000000 + floatval(microtime()) - $begin_time;
echo $end_time . "\n";

время потраченое 0.47229799628258
V
Valentin Kuzmenko 22 октября 2014г в 05:33 #
Первый листинг выполняется в десятки раз быстрее, если я слишком примитивно сделал сравнения то поправьте, меня интересует производительность, скорость, гибкость, и т.д. и т.п.
Fi1osof1
Fi1osof 22 октября 2014г в 22:16 #
В общих чертах верно. Но говорю же: разные цели - разные инструменты. У меня как правило все строится на выборках данных и все. А своя система процессоров позволяет менять логику централизованно. Если бы не было этой системы процессоров, то пришлось бы скорее всего использовать сами объекты, так как иногда нужна какая-то дополнительная логика, а она где-то должны храниться, чтобы всегда была на месте. Приведу пару небольших примеров.
Вот довольно не маленький класс элемента (galItem - картинка) в компоненте Gallery. Что в нем есть?
- Специфическая обработка метода get().
- Удаление физического файла картинки при вызове remove().
И куча еще всего.
Вот здесь или мы пишем все в сам класс, чтобы всегда можно было использовать, к примеру, $modx->getObject('galItem', $id)->get('relativeImage'), или пишем процессор, который будет получать чистые данные из БД и выполнять нужные действия. Для меня, к примеру, процессор предпочтительней. Он в 99.9% случаев будет работать быстрее. Но с объектами бывает удобнее работать. К тому же, если в объекте, к примеру, прописана специфическая обработка того же метода remove(), то откуда бы не вызвали удаление объекта, всегда этот метод будет отработан, даже если объект удаляется паровозом за связанными объектами.
AlexBaks1
AlexBaks 23 октября 2014г в 17:20 #
Процессор выполняет для бекенда модекса туже роль что и контроллер в классическом понимание, в некоторых случаях его функционал при работе с кастумными классами мягко говоря избыточен. Вот здесь я описывал возможность вызова процессора с произвольным кодом что дает легкость кода спинетов с нормальным return

пример
Fi1osof1
Fi1osof 23 октября 2014г в 19:37 #
Справедливости ради следует отметить, что контроллеры в MODX-е тоже есть, в том числе и для админки. А в MODx2.3+ там по-моему модель контроллеров еще более ярко выраженная стала. А процессоры - это просто более узкопрофильная штука. Один процессор - одно действие. Свое видение на это я когда-то писал здесь.
AlexBaks1
AlexBaks 23 октября 2014г в 23:18 #
Справедливости ради следует отметить, что в MODX реализация контроллеров на уровне каменного века то есть не какая.

В современных фремворках есть контроллеры вызываемые с помощью роутинга а там далее по action и все это может быть в одном классе.

Из чего следует что контроллер в модексе отвечает за группу action то есть процессоров которые не где не в каких конфигах не отмечены и о их существовании можно узнать только лишь обноружев физический фаил.

На самом деле все очень грустно, разработчикам MODX надо было не дизайн новый вкручивать а допилить namecpace в XPDO 3 добавить нормальный роутинг контроллеры вот тогда MODX можно было бы называть фремворком.

Fi1osof1
Fi1osof 23 октября 2014г в 23:24 #
Алексей, MODX очень даже еще фреймворк. Да, он сейчас не во всем соответствует последним тенденциям и технологиям, но это не делает его не фреймворкам. Несколько лет назад, когда он появился, он много в чем делал своих конкурентов того времени. А вот со временем да, какие-то новинки в него не попали. Но это не означает, что он плох. Я много с чем работал, и по прежнему останусь пока работать с ним. Где-то новое что-то появляется, а что-то не доработано. И не забывай про обратную совместимость. Нельзя сейчас просто так взять и новые технологии внедрить. Одно лечишь, другое калечишь. Я вот до сих пор на 2.3 не перехожу, потому что не все там идеально и не все стабильно. А ведь там мало что изменили. А ты говоришь сейчас о глобальных новшествах. В конце концов каждый выбирает себе инструмент сам. Нравится что-то другое - никто не запрещает использовать.
AlexBaks1
AlexBaks 23 октября 2014г в 23:34 #
Да в том то и дело что он устарел,и может имеет смысл пересобрать CMS в новом исполнении на базе тогоже XPDO 3.0 которое практически собралось и запустилось после легкого допила.

А собрать новое едро можно с учетом современного проектирование, меньше зависимостей более модульнее и прочие плюшки.
Fi1osof1
Fi1osof 23 октября 2014г в 23:52 #
Алексей, ты имеешь полное право взять xPDO3.0 и создать новый качественный фреймворк. Просто не забудь указать, что ты использовал, а так можешь делать все, что угодно. Меня в общих чертах почти все в MODX-е устраивает.
Есть хорошая поговорка: "Есть хреновые вещи, написаные гениально, а есть гениальные, написаные хреново". Так вот, конечного пользователя не волнует что и как там написано. Его волнует какой он в итоге получает продукт. На MODX Revolution, какой бы он не был не современный, можно писать отличные вещи и в большом количестве :)
На том холивары заканчиваем, мне не интересно это.
AlexBaks1
AlexBaks 24 октября 2014г в 00:05 #
Все понятно. для написание новой CMS используя используя современные фреймоворки плюс тод же XPDO (не чего немугу с собой поделать но из ActiveRecord на php он мне больше всех нравится) по трудо затратам и времени уйдет столькоже сколько сейчас на MODX сделать нормальный более менее сложный компонент типа корзины тойже самой.

Вы абсолютно правы каждый сам решает на что ему свое время тратить...

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

И тогда может быть благодаря МодексКлубу собралась инициативная группа и создала бы новую улучшенную CMS на базе XPDO.
Fi1osof1
Fi1osof 24 октября 2014г в 00:09 #
Скоро на сайте появится кое-что гораздо более интересное и приятное, чем просто контакты))) Просто надо чуть-чуть подождать. Я писал уже людям про необходимость донейтов, но нет донейтов сейчас вообще (Скорее всего кризис. Весной было лучше с донейтами, хоть и пользователей было меньше). Так что сейчас вот кое-какую коммерческую работу делаю, а вот как доделаю и появится время, обещаю очень интересные новшества на сайте :) До нового года обязательно все появится.
AlexBaks1
AlexBaks 24 октября 2014г в 00:08 #
Кстате не будем забывать так же о Etomite прародителе MODX.
AlexBaks1
AlexBaks 23 октября 2014г в 23:41 #
к примеру в место того что бы писать вот так


require_once dirname(dirname(__FILE__)).'/getdata.class.php';
class modSiteWebResourcesGetdataProcessor extends modSiteWebGetdataProcessor{


при поддержки неймспейса можно писать вот так


namecpace Modxsite\Controller
class modSiteWebResourcesGetdataProcessor extends Web\Getdata{
vanchelo1
vanchelo 24 октября 2014г в 13:48 #
Вам никто не мешает зарегать свой автолоадер через
spl_autoload_register(function($class) {
if (strpos($class, 'Modxsite\\') === 0) {
$name = substr($class, strlen('Modxsite'));
require MODX_CORE_PATH . 'components/modxsite/' . strtr($name, '\\', DIRECTORY_SEPARATOR) . '.php';
}
});
Fi1osof1
Fi1osof 24 октября 2014г в 15:08 #
Вот, как все просто :)
vanchelo1
vanchelo 24 октября 2014г в 19:05 #
Только придется следовать стандартам, соблюдать регистр, именование классов и папок или заточить под MODX т.к. так у классов суффикс '.class.php' да еще и с маленькой буквы, можно конечно в автолоадере к нижнему регистру приводить, да вообще там можно написать че хошь)
vanchelo1
vanchelo 24 октября 2014г в 19:19 #
Если эта тема кого-то интересует можно поэксперементировать с автозагрузкой
Tramp13571
Tramp1357 24 октября 2014г в 18:56 #
А можно суть поподробнее, пожалуйста :)
vanchelo1
vanchelo 24 октября 2014г в 19:03 #
Подробнее о чем? Если я пойму что вам нужно, может и смогу помочь)
Tramp13571
Tramp1357 24 октября 2014г в 19:10 #
про автолоадер. и как это использовать
vanchelo1
vanchelo 24 октября 2014г в 19:40 #
Дайте больше подробностей, тот пример просто как иллюстрация что это делается элементарно)) Куда вам нужно автолоадер прикрутить, структура папок вашего компонента интересует, можно скриншот дерева
Fi1osof1
Fi1osof 24 октября 2014г в 20:33 #
Вань, да просто небольшой пример, вместе с подключением и т.п. Просто чтобы понятно было ребятам как это работает и как применять. У лучше в отдельном топике, чтобы оффтоп не разводить, ибо наверняка комментов будет много.
Tramp13571
Tramp1357 24 октября 2014г в 22:16 #
Да структура стандартная для shopmodxbox. И действительно, если можно, в отдельном топике :)
Tramp13571
Tramp1357 24 октября 2014г в 18:58 #
суть чуть
AlexBaks1
AlexBaks 24 октября 2014г в 22:45 #
Так у меня давно уже vendor подключен, и еще целая куча плюшек, вот только на MODX это все меньше становится похожим, по этому я и ставлю вопрос что требуется пересмотреть архитектуру, и собрать новый вариант.
Fi1osof1
Fi1osof 24 октября 2014г в 23:13 #
Никто не будет пересматривать архитектуру только потому что ты вышел на новый уровень. Потому что это фреймворк, и у разных разработчиков разные подходы к программированию. Элементарно посмотри на серию наших модулей и тех же PDO-модулей Безумкина. Здесь абсолютно разные парадигмы разработки и использовать одни модули одной серии не видится возможным или разумным с серией других модулей. Нет здесь речи о хорошести или нехорошести этих модулей, речь именно о разных подходах, разных технологиях. Соответственно его модули очень годятся под его минишоп, и не годятся под наш shopModx, и наоборот, наши модули для нас хороши, но не будут дружить с его минишопом. Так почему же мы должны настаивать на том, чтобы MODX перекроили именно под нас? Просто потому что нам от этого будет хорошо? Нам будет. А 99% MODX-еров не используют такие технологии. Поэтому наши хотелки просто так никто не будет реализовывать. И хотелки Василия тоже никто не будет реализовывать. И твои хотелки тоже просто так никто реализовывать не будет. Но если у тебя есть четкое понимание как сделать лучше, то не высказывай свои соображения, а фигачь пуллреквест. Там его рассмотрят, и если он интересен и обратная совместимость 100%, то может и примут. Но вот посмотри один из моих PR. Про него я писал здесь. Это очень полезный PR, и занимает всего одну строчку. Так вот, не смотря на то, что это всего одна строчка и никак не влияет на текущий MODX, а только дополняет его (так как третий параметр в функции появляется), его планирую ввести только в версии MODX2.4, то есть даже не в 2.3. Поэтому все эти обсуждения хотелок ИМХО - трата времени. Хочешь - делай. Но обсуждать долго нет смысла и выражать особо свое мнение. Просто делай молча и все. У меня 22 пуллреквеста в MODX, это только по MODX Revo. Еще есть в xPDO и несколько багфиксов по MODX Evo и 0.9
AlexBaks1
AlexBaks 24 октября 2014г в 23:24 #
Вот в этом то и проблема что не соблюдаются стандарты потому и не подходят разные модули от разных "Шопов"
А это как раз и доказывает костность MODX и то что он не является фремворком. Взять туже симфонию все кто хотят пишут компоненты но так как они все написаны по стандарту то дружить из между собой не составляет проблем.

Я невижу смысла в пул реквестах в существующий MODX на XPDO 2.0 тогда когда есть XPDO 3.0 вот где будущие вот над ним я сейчас и работаю.

XPDO 2.0 это прошлое.
AlexBaks1
AlexBaks 25 октября 2014г в 00:10 #
Вот всем кому интересно https://github.com/opengeek/xpdo/tree/release-3.0 от великого и ужасного Jason Coward даже он понимает что отсутствие неймспейсов это прошлый век.

правда без танцев с бубнами не запустишь.
Fi1osof1
Fi1osof 25 октября 2014г в 00:19 #
А это как раз и доказывает костность MODX и то что он не является фремворком.

Алексей, мне кажется ты некоторые вещи путаешь. Дело не в MODX-е, а дело в данном случае в конечных разработчиках. Потому то у нас и методы реализованы разные, что MODX - это ФРЕЙМВОРК. Он позволяет делать что угодно и как угодно. И это уже на моей совести лежит как я его использую. А вот если бы это была узкопрофильная ЦМСка, то она бы скорее всего меня заставила работать более стандартизировано.
AlexBaks1
AlexBaks 25 октября 2014г в 00:25 #
что MODX - это ФРЕЙМВОРК. Он позволяет делать что угодно и как угодно.

На чистом php тоже все сделать можно, весь вопрос какой ценой, то что можно сделать за пару часов на современных фремворках в MODX решается за пару дней с кучай велосипедов, а самое главное полное отсутствие юнит тестов, что любую серьезную разработку со сложной бизнес логикой сводит на нет.
Fi1osof1
Fi1osof 25 октября 2014г в 00:31 #
Алексей, не суди по себе. Реально. То, что человек не умеет летать на самолетах, еще не говорит о том, что самолеты не пригодны для полетов, и что вообще они бесполезные создания. Лучше сразу на ракеты садиться. Многое зависит не только от инструмента, но и от степени владения этим инструментом. Поэтому не надо давать оценку MODX-у глобально, а скажи просто "я не умею им пользоваться, а вот то я знаю лучше, я на том делаю быстрее и качественней". Я всегда говорил, если человек хорошо знает битрикс, он сделает магазин на битриксе лучше, чем н MODX-е. Не потому что битрикс лучше, а потому что он его знает лучше. И наоборот. Меня твои утверждения на счет сроков сильно удивляют. То, что я делаю за два дня - это очень и очень не мало. Все, больше на твои комментарии здесь не отвечу. Кадый останется при своем мнении.
AlexBaks1
AlexBaks 25 октября 2014г в 00:37 #
-1
Все с вами понятно видимо мы смотрим на проектирование и веб разработку с разных уровней... Разговор действительно бессмыслен время все само поставит по местам....
Fi1osof1
Fi1osof 25 октября 2014г в 00:38 #
Респект за понимание.
AlexBaks1
AlexBaks 24 октября 2014г в 22:48 #
Основная проблема, эта отсутствие неймспейса в XPDO, остальное все синтаксический сахар.
Авторизуйтесь или зарегистрируйтесь (можно через соцсети ), чтобы оставлять комментарии.