Итак, мысль... В свое время мы уже обсуждали идею мультиуровневой иерархии в рамках Клуба. Основной принцип - "Вассал моего вассала - не мой вассал". То есть каждый берет себе "подопечных", и занимается и работает только с ними. А те, в свою очередь, берут себе своих подопечных, и занимаются ими. И так далее... Людей первого уровня как бы и не особо волнуют люди третьего звена, как и людей второго уровня не волнуют люди четвертого и далее уровня. (Оговорюсь на всякий случай: здесь и далее речь о уровнях только в самой структуре. Ни на какие отличия людей это никак не оценивается. Термин использован просто для понимания). В свою очередь люди третьего уровня взаимодействуют только с четвертым уровнем (как с подчиненными), с третьим уровнем (как с напарниками) и вторым уровнем (как с руководством). При этом со вторым уровнем не всем, а только с непосредственным начальником. Это все просто проговорил, чтобы напомнить о чем речь была и так, концепция в общих чертах. А вот сейчас относительно свежие мысли. На самом деле сначала в голову пришла цель, а только потом некоторые идеи, которые вроде как могут помочь в реализации цели. Итак, нет никакого смысла делать какую-то структуру и т.п., если не иметь в ней политики обязательств, ответственности и т.п. То есть, если у меня есть какие-то подчиненные, по идее, я должен иметь возможность что-то им сказать, а они должны сделать. Если не делают - значит расставание (здесь и далее Я - это абстрактное, просто рассуждения для наглядности). Я тут вижу следующую пользу для Клуба: к примеру, я говорю своим вассалам, что каждый должен поставить по лайку за какую-то статью, и всем своим вассалам сказать, чтобы тоже кликнули. При четко организованной структуре можно получить 100500 лайков :) Здесь же была попутная идея - типа каждый должен вести активность на сайте, и заходить на него хотя бы раз в неделю. Это может способствовать увеличению посещаемости сайта. И вот здесь как раз возникла "проблема" - далеко не всем будут интересны подобные "игры", то есть не каждое задание понравится всем, потому что люди - разные. И вот в этом возможно кроется истина - разные. То есть нельзя всех просто сделать вассалами. Нужны разные "титулы" и специализации. Для чего это нужно? Дело не только в том, что не каждый захочет лайк ставить просто потому что ему сказали. Дело в принципе непосредственное отношение к организации структуры имеет. Разворачиваю мысль: вот мне нравится учить людей (не всех конечно, но кому-то вообще это не нравится делать). То есть я могу себе взять пару-тройку учеников и их учить, тем более, что у меня есть для этого какие-то знания. Образно говоря, у меня есть несколько хай-слотов для вассалов-учеников:) Но могу еще и парочку евангелистов себе на баланс взять. А вот не особо общительному программисту, который просто пишет сайты, а потом своими делами занимается - ему вассалы могут и не понадобиться, может только парочка напарников в одном уровне. В общем, надо придумать какие-то титулы/специальности, которые позволили бы как-то разделить различные типы людей. Это бы помогло и задания различные для людей давать, и какую-то более гибкую стратегию развивать, и обязанности какие-то вводить. К примеру, у меня в команде уже есть несколько хороших программистов. Я от них не требую ходить и кучу статей писать, потому что они заняты своим делом. И я это знаю без постоянного контроля их деятельности. Но вот мне понадобился евангелист. Я посмотрел среди членов Клуба кто там есть интересный евангелист, кого бы можно было к себе подтянуть. Я уже не буду смотреть тех, у кого отмечено, что он программист, я посмотрю только евангелистов, и вот из них я уже буду выбирать кто лучше. Вот как-то так... За этим тянется еще шлейф идей, но это уже на потом. У кого какие идеи есть?
Всем привет! Если вы получили это письмо, то вы - один из четырех избранных! :)))) Сюда больше никто не имеет доступа. То есть это самый закрытый из блогов, более закрытый, чем MODX-Клуб, куда имеют доступ члены Клуба (коих на сегодня уже не мало). Памятуя слова Чехова, что "не записанная мысль - потерянная мысль", я решил записать кое-какие пришедшие мне в голову мысли. Когда думал куда записать, на бумагу или в гугл.докс, решил, что на сайте Клуба будет лучше всего записать, ибо касается это его напрямую. Сейчас напишу все в отдельный топик. А этот был просто в качестве краткой новости.
Первый листинг выполняется в десятки раз быстрее, если я слишком примитивно сделал сравнения то поправьте, меня интересует производительность, скорость, гибкость, и т.д. и т.п.
провёл для себя эксперимент выявить каким способом быстрее достать данные, например достать id=185 и его tv параметр price0 привожу листинги кодов
- $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
По своему опыту могу сказать: стоит попробовать процессоры раз, и про сниппеты забудешь :)
Ваня уже в целом ответил. Да, главные минусы сниппетов (а getResources (здесь и далее подразумевается и getProducts, так как getProducts - это модифицированный getResources) - это сниппеты), что они возвращают только строковые результаты и что их нельзя расширять и т.п. Плюс к этому я бы еще добавил кое что:
- Рост кеша страницы. Сниппет и надо вызывать как сниппет, хоть он будет тегом прописан (и его потом MODX-парсер вызовет), хоть вы сами через $modx->runSnippet() вызовите. И прикол в том, что в любом случае кеш кода сниппета будет сложен в кеш страницы. В общих чертах про это писал здесь. В итоге даже при заходе на полностью кешированную страницу, даже если ничего выполняться не будет, инициируется довольно большой кеш-файл, который в итоге набивается в большой массив. А это потеря и времени, и ресурсов (в том числе памяти).
- getResources оперирует объектами, в то время как getdata-процессор только данными. В итоге разница в скорости и ресурсах в разы. Правда здесь минус getdata-процессора - не учитываются права на запрашиваемые данные (то есть если делать выборку документов из раздела, в котором часть документов - привилегированные, getResources выдаст только доступные документы, а getdata-процессор все документы). Но это тоже лечится. Здесь же выполняются выборки с учетом прав. Есть еще всякие мелочи, но не буду глубоко копаться.
да кстати замерил даную страницу http://developers.google.com/speed/pagespeed показывает Это время общее, включая пинг и т.п. А есть замеры на стороне самого сервера. Вот данные этой страницы: Memory: 13.0902 Mb TotalTime: 0.4274 s Но здесь хоть и не большая, но социальная сеть. Это один из крупнейших проектов, который приходилось делать (с учетом всех политик безопасностей, инфоблоков и т.п.). А средний корпоративный сайт или магазин вполне может работать быстрее. да наткнулся на сайты которые просто уговаривали кэшировать для того что бы сайт просто летал Берите на вооружение эту технологию :).
Я согласен, что появляются очень много зависимостей, и я уже с этим сталкнулся, так как одно изменение требует эти обновления и на других страницах. да наткнулся на сайты которые просто уговаривали кэшировать для того что бы сайт просто летал. Необходимо оптимизировать и переписать функционал всего сайта, что бы отказаться от кэширования, и по этому случаю, изучаю ваши разработки которые в основном не используют кэширование и хотелось бы иметь, неплохую документацию по вашим продуктам и в одном месте, да кстати замерил даную страницу http://developers.google.com/speed/pagespeed показывает По результатам тестирования время ответа вашего сервера составило 0,61 секунды Да и спасибо за быстрый отзыв на вопросы, и за комментарии и советы
Гибкость процессоров только в наследовании и том что он возвращает любой тип данных, а сниппет без танцев с бубнов всегда возвращает строку. А так по сути процессор это просто классы со стандартизированной в рамках MODX определенной логикой, в MODX их почему-то назвали именно так)