Powered by Prisma CMS

Читайте все статьи на prisma-cms.com

21 окт. 2014 г., 15:15

Процессоры как замена getResources, getProducts

Николай, позволь спросить тебя, на счёт процессоров, насколько они будут работать быстрее и эффективней чем стандартный getResources или похожий getProducts? Большинство тех кто создаёт своё детище естественно его и продвигает, и возникает вопрос, а насколько эффективней данный продукт, чем остальные похожие по своей работе пакеты, сниппеты, прагины. Я читал некоторые твои статьи(топики) и там ты никого не упрашиваешь пользоваться твоим продуктом, а порой даже отговариваешь, так как что бы работать со многими твоими продуктами, необходимо не мало приложить и своих усилий + приложить к этому голову с ясным умом, не всем под силу использовать твои решения. Есть ли у тебя некое сравнение, может ты когда то делал такие тесты как, скорость, удобство в использование, гибкость в настраивании и т.д. если есть такие характеристики то хотелось бы увидеть.
Гибкость процессоров только в наследовании и том что он возвращает любой тип данных, а сниппет без танцев с бубнов всегда возвращает строку. А так по сути процессор это просто классы со стандартизированной в рамках MODX определенной логикой, в MODX их почему-то назвали именно так)
Ваня уже в целом ответил. Да, главные минусы сниппетов (а getResources (здесь и далее подразумевается и getProducts, так как getProducts - это модифицированный getResources) - это сниппеты), что они возвращают только строковые результаты и что их нельзя расширять и т.п. Плюс к этому я бы еще добавил кое что: 1. Рост кеша страницы. Сниппет и надо вызывать как сниппет, хоть он будет тегом прописан (и его потом MODX-парсер вызовет), хоть вы сами через $modx->runSnippet() вызовите. И прикол в том, что в любом случае кеш кода сниппета будет сложен в кеш страницы. В общих чертах про это писал здесь. В итоге даже при заходе на полностью кешированную страницу, даже если ничего выполняться не будет, инициируется довольно большой кеш-файл, который в итоге набивается в большой массив. А это потеря и времени, и ресурсов (в том числе памяти). 2. getResources оперирует объектами, в то время как getdata-процессор только данными. В итоге разница в скорости и ресурсах в разы. Правда здесь минус getdata-процессора - не учитываются права на запрашиваемые данные (то есть если делать выборку документов из раздела, в котором часть документов - привилегированные, getResources выдаст только доступные документы, а getdata-процессор все документы). Но это тоже лечится. Здесь же выполняются выборки с учетом прав. Есть еще всякие мелочи, но не буду глубоко копаться.
По своему опыту могу сказать: стоит попробовать процессоры раз, и про сниппеты забудешь :)
провёл для себя эксперимент выявить каким способом быстрее достать данные, например достать 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
Первый листинг выполняется в десятки раз быстрее, если я слишком примитивно сделал сравнения то поправьте, меня интересует производительность, скорость, гибкость, и т.д. и т.п.
В общих чертах верно. Но говорю же: разные цели - разные инструменты. У меня как правило все строится на выборках данных и все. А своя система процессоров позволяет менять логику централизованно. Если бы не было этой системы процессоров, то пришлось бы скорее всего использовать сами объекты, так как иногда нужна какая-то дополнительная логика, а она где-то должны храниться, чтобы всегда была на месте. Приведу пару небольших примеров. Вот довольно не маленький класс элемента (galItem - картинка) в компоненте Gallery. Что в нем есть? - Специфическая обработка метода get(). - Удаление физического файла картинки при вызове remove(). И куча еще всего. Вот здесь или мы пишем все в сам класс, чтобы всегда можно было использовать, к примеру, $modx->getObject('galItem', $id)->get('relativeImage'), или пишем процессор, который будет получать чистые данные из БД и выполнять нужные действия. Для меня, к примеру, процессор предпочтительней. Он в 99.9% случаев будет работать быстрее. Но с объектами бывает удобнее работать. К тому же, если в объекте, к примеру, прописана специфическая обработка того же метода remove(), то откуда бы не вызвали удаление объекта, всегда этот метод будет отработан, даже если объект удаляется паровозом за связанными объектами.
Процессор выполняет для бекенда модекса туже роль что и контроллер в классическом понимание, в некоторых случаях его функционал при работе с кастумными классами мягко говоря избыточен. Вот здесь я описывал возможность вызова процессора с произвольным кодом что дает легкость кода спинетов с нормальным return
Справедливости ради следует отметить, что контроллеры в MODX-е тоже есть, в том числе и для админки. А в MODx2.3+ там по-моему модель контроллеров еще более ярко выраженная стала. А процессоры - это просто более узкопрофильная штука. Один процессор - одно действие. Свое видение на это я когда-то писал здесь.
Справедливости ради следует отметить, что в MODX реализация контроллеров на уровне каменного века то есть не какая.
В современных фремворках есть контроллеры вызываемые с помощью роутинга а там далее по action и все это может быть в одном классе.
Из чего следует что контроллер в модексе отвечает за группу action то есть процессоров которые не где не в каких конфигах не отмечены и о их существовании можно узнать только лишь обноружев физический фаил.
На самом деле все очень грустно, разработчикам MODX надо было не дизайн новый вкручивать а допилить namecpace в XPDO 3 добавить нормальный роутинг контроллеры вот тогда MODX можно было бы называть фремворком.
Алексей, MODX очень даже еще фреймворк. Да, он сейчас не во всем соответствует последним тенденциям и технологиям, но это не делает его не фреймворкам. Несколько лет назад, когда он появился, он много в чем делал своих конкурентов того времени. А вот со временем да, какие-то новинки в него не попали. Но это не означает, что он плох. Я много с чем работал, и по прежнему останусь пока работать с ним. Где-то новое что-то появляется, а что-то не доработано. И не забывай про обратную совместимость. Нельзя сейчас просто так взять и новые технологии внедрить. Одно лечишь, другое калечишь. Я вот до сих пор на 2.3 не перехожу, потому что не все там идеально и не все стабильно. А ведь там мало что изменили. А ты говоришь сейчас о глобальных новшествах. В конце концов каждый выбирает себе инструмент сам. Нравится что-то другое - никто не запрещает использовать.
Да в том то и дело что он устарел,и может имеет смысл пересобрать CMS в новом исполнении на базе тогоже XPDO 3.0 которое практически собралось и запустилось после легкого допила.
А собрать новое едро можно с учетом современного проектирование, меньше зависимостей более модульнее и прочие плюшки.
к примеру в место того что бы писать вот так
require_once dirname(dirname(__FILE__)).'/getdata.class.php'; class modSiteWebResourcesGetdataProcessor extends modSiteWebGetdataProcessor{
при поддержки неймспейса можно писать вот так
namecpace Modxsite\Controller class modSiteWebResourcesGetdataProcessor extends Web\Getdata{
Алексей, ты имеешь полное право взять xPDO3.0 и создать новый качественный фреймворк. Просто не забудь указать, что ты использовал, а так можешь делать все, что угодно. Меня в общих чертах почти все в MODX-е устраивает. Есть хорошая поговорка: "Есть хреновые вещи, написаные гениально, а есть гениальные, написаные хреново". Так вот, конечного пользователя не волнует что и как там написано. Его волнует какой он в итоге получает продукт. На MODX Revolution, какой бы он не был не современный, можно писать отличные вещи и в большом количестве :) На том холивары заканчиваем, мне не интересно это.
Все понятно. для написание новой CMS используя используя современные фреймоворки плюс тод же XPDO (не чего немугу с собой поделать но из ActiveRecord на php он мне больше всех нравится) по трудо затратам и времени уйдет столькоже сколько сейчас на MODX сделать нормальный более менее сложный компонент типа корзины тойже самой.
Вы абсолютно правы каждый сам решает на что ему свое время тратить...
Холивар заводить даже и не собирался, мое дело предложить в любом случаи всегда найдется тот кому это будет интересно и если бы вы добавили возможность вставлять свои контакты в профеле, то то кому интересно смог бы мне написать.
И тогда может быть благодаря МодексКлубу собралась инициативная группа и создала бы новую улучшенную CMS на базе XPDO.
Кстате не будем забывать так же о Etomite прародителе MODX.
Скоро на сайте появится кое-что гораздо более интересное и приятное, чем просто контакты))) Просто надо чуть-чуть подождать. Я писал уже людям про необходимость донейтов, но нет донейтов сейчас вообще (Скорее всего кризис. Весной было лучше с донейтами, хоть и пользователей было меньше). Так что сейчас вот кое-какую коммерческую работу делаю, а вот как доделаю и появится время, обещаю очень интересные новшества на сайте :) До нового года обязательно все появится.
Вам никто не мешает зарегать свой автолоадер через
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'; } });
Вот, как все просто :)
А можно суть поподробнее, пожалуйста :)
Подробнее о чем? Если я пойму что вам нужно, может и смогу помочь)
Только придется следовать стандартам, соблюдать регистр, именование классов и папок или заточить под MODX т.к. так у классов суффикс '.class.php' да еще и с маленькой буквы, можно конечно в автолоадере к нижнему регистру приводить, да вообще там можно написать че хошь)
про автолоадер. и как это использовать
Если эта тема кого-то интересует можно поэксперементировать с автозагрузкой
Дайте больше подробностей, тот пример просто как иллюстрация что это делается элементарно)) Куда вам нужно автолоадер прикрутить, структура папок вашего компонента интересует, можно скриншот дерева
Вань, да просто небольшой пример, вместе с подключением и т.п. Просто чтобы понятно было ребятам как это работает и как применять. У лучше в отдельном топике, чтобы оффтоп не разводить, ибо наверняка комментов будет много.
Да структура стандартная для shopmodxbox. И действительно, если можно, в отдельном топике :)
Так у меня давно уже vendor подключен, и еще целая куча плюшек, вот только на MODX это все меньше становится похожим, по этому я и ставлю вопрос что требуется пересмотреть архитектуру, и собрать новый вариант.
Основная проблема, эта отсутствие неймспейса в XPDO, остальное все синтаксический сахар.
Никто не будет пересматривать архитектуру только потому что ты вышел на новый уровень. Потому что это фреймворк, и у разных разработчиков разные подходы к программированию. Элементарно посмотри на серию наших модулей и тех же PDO-модулей Безумкина. Здесь абсолютно разные парадигмы разработки и использовать одни модули одной серии не видится возможным или разумным с серией других модулей. Нет здесь речи о хорошести или нехорошести этих модулей, речь именно о разных подходах, разных технологиях. Соответственно его модули очень годятся под его минишоп, и не годятся под наш shopModx, и наоборот, наши модули для нас хороши, но не будут дружить с его минишопом. Так почему же мы должны настаивать на том, чтобы MODX перекроили именно под нас? Просто потому что нам от этого будет хорошо? Нам будет. А 99% MODX-еров не используют такие технологии. Поэтому наши хотелки просто так никто не будет реализовывать. И хотелки Василия тоже никто не будет реализовывать. И твои хотелки тоже просто так никто реализовывать не будет. Но если у тебя есть четкое понимание как сделать лучше, то не высказывай свои соображения, а фигачь пуллреквест. Там его рассмотрят, и если он интересен и обратная совместимость 100%, то может и примут. Но вот посмотри один из моих PR. Про него я писал здесь. Это очень полезный PR, и занимает всего одну строчку. Так вот, не смотря на то, что это всего одна строчка и никак не влияет на текущий MODX, а только дополняет его (так как третий параметр в функции появляется), его планирую ввести только в версии MODX2.4, то есть даже не в 2.3. Поэтому все эти обсуждения хотелок ИМХО - трата времени. Хочешь - делай. Но обсуждать долго нет смысла и выражать особо свое мнение. Просто делай молча и все. У меня 22 пуллреквеста в MODX, это только по MODX Revo. Еще есть в xPDO и несколько багфиксов по MODX Evo и 0.9
Вот в этом то и проблема что не соблюдаются стандарты потому и не подходят разные модули от разных "Шопов" А это как раз и доказывает костность MODX и то что он не является фремворком. Взять туже симфонию все кто хотят пишут компоненты но так как они все написаны по стандарту то дружить из между собой не составляет проблем.
Я невижу смысла в пул реквестах в существующий MODX на XPDO 2.0 тогда когда есть XPDO 3.0 вот где будущие вот над ним я сейчас и работаю.
XPDO 2.0 это прошлое.
Вот всем кому интересно https://github.com/opengeek/xpdo/tree/release-3.0 от великого и ужасного Jason Coward даже он понимает что отсутствие неймспейсов это прошлый век.
правда без танцев с бубнами не запустишь.
А это как раз и доказывает костность MODX и то что он не является фремворком.
Алексей, мне кажется ты некоторые вещи путаешь. Дело не в MODX-е, а дело в данном случае в конечных разработчиках. Потому то у нас и методы реализованы разные, что MODX - это ФРЕЙМВОРК. Он позволяет делать что угодно и как угодно. И это уже на моей совести лежит как я его использую. А вот если бы это была узкопрофильная ЦМСка, то она бы скорее всего меня заставила работать более стандартизировано.
что MODX - это ФРЕЙМВОРК. Он позволяет делать что угодно и как угодно.
На чистом php тоже все сделать можно, весь вопрос какой ценой, то что можно сделать за пару часов на современных фремворках в MODX решается за пару дней с кучай велосипедов, а самое главное полное отсутствие юнит тестов, что любую серьезную разработку со сложной бизнес логикой сводит на нет.
Алексей, не суди по себе. Реально. То, что человек не умеет летать на самолетах, еще не говорит о том, что самолеты не пригодны для полетов, и что вообще они бесполезные создания. Лучше сразу на ракеты садиться. Многое зависит не только от инструмента, но и от степени владения этим инструментом. Поэтому не надо давать оценку MODX-у глобально, а скажи просто "я не умею им пользоваться, а вот то я знаю лучше, я на том делаю быстрее и качественней". Я всегда говорил, если человек хорошо знает битрикс, он сделает магазин на битриксе лучше, чем н MODX-е. Не потому что битрикс лучше, а потому что он его знает лучше. И наоборот. Меня твои утверждения на счет сроков сильно удивляют. То, что я делаю за два дня - это очень и очень не мало. Все, больше на твои комментарии здесь не отвечу. Кадый останется при своем мнении.
Все с вами понятно видимо мы смотрим на проектирование и веб разработку с разных уровней... Разговор действительно бессмыслен время все само поставит по местам....
Респект за понимание.

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