Список самых "тяжелых модулей"

Главные вкладки

Комментарии

Аватар пользователя Stan.Ezersky Stan.Ezersky 23 сентября 2010 в 22:11

Уточните, для каких хостингов «тяжёлых» и в чём «проблемных»?

У меня много сайтов на виртуальных хостингах с Panels, Views. Все сайты с CCK и Pathauto. Я не считаю их тяжёлыми, тем более, проблемными.

Аватар пользователя VasyOK VasyOK 23 сентября 2010 в 22:18

Самый тяжелый модуль называется drupal. А вообще действительно, когда хостинг нормальный о тяжелости модулей как то не приходится задумываться.

Запара начинается, когда нужно делать что-то на хостинге, который выбирали без меня. Тогда действительно Views тяжелит. Но можно сделать на другом а потом просто перенести базу. Как ни странно, Sypex Dumper грузит хостинг меньше чем Drupal.

Аватар пользователя Stutzer Stutzer 23 сентября 2010 в 23:13

определили бы критерии тяжести (количество запросов на загрузку, потребляемая память), варианты решения, альтернативы, сравнение... а то пустословие какой-то.
ну тяжелый вьюз, ну и что теперь?

Аватар пользователя Alex_on Alex_on 24 сентября 2010 в 0:33

Про тяжесть писать не буду, т.к. непонятно что имелось в виду.
Про проблемность:
Views-ковыряться много надо зато и возможностей много
Panel-пока не использовал
Pathauto-поставил и забыл. Все бы модули были такие проблемные Smile

Аватар пользователя kyky kyky 24 сентября 2010 в 2:14

Если cck и views действительно необходимы, то Panel заменяется темизацией, регионами и тд. От него запросто можно отказаться.
Устанавливая любой модуль, нужно понимать, зачем он нужен и возможно ли обойтись без него.

Аватар пользователя Stutzer Stutzer 24 сентября 2010 в 2:24

kyky wrote:
Если cck и views действительно необходимы, то Panel заменяется темизацией, регионами и тд. От него запросто можно отказаться.
Устанавливая любой модуль, нужно понимать, зачем он нужен и возможно ли обойтись без него.

Про panel согласен, никогда не понимал толком, чем обусловлена его популярность

Аватар пользователя darkdim darkdim 11 октября 2010 в 14:22

Stutzer wrote:
kyky wrote:
Если cck и views действительно необходимы, то Panel заменяется темизацией, регионами и тд. От него запросто можно отказаться.
Устанавливая любой модуль, нужно понимать, зачем он нужен и возможно ли обойтись без него.

Про panel согласен, никогда не понимал толком, чем обусловлена его популярность

Панельки позволяют оперативно решать вопросы изменения в структуре без необходимости поправлять шаблон. + в панельках есть механизм кеширования, так что его популярность тем и обусловлена - облегчает администрирование.

Аватар пользователя glu2006 glu2006 24 сентября 2010 в 9:32

Панели очень прикольный модуль, я был о нем плохого мнения пока не поюзал его пару раз, его необходимость понимаешь когда у тебя на сайте 20 и более разновидностей страниц, либо у них сложная структура и т.д. посмотрите на http://www.ppr.com или http://www.runewsweek.ru, парни они на панелях, а представляете сколько мозгоруконервотраха на регионах и блоках это делать, а саппортить и админить, этож какой модер должен там сидеть шарящий.
Тем более в панелях под 6-ку товарищ merlinofchaos (кстати папа вьюсов вдруг кто-то не знает) если можно так сказать вложил душу.

Аватар пользователя run run 24 сентября 2010 в 9:49

"glu2006" wrote:
Панели очень прикольный модуль

Под 5-ку пробовал - не понравилось и забил на него. Попробую под 6-ку.
"Nikolay Cowpland" wrote:
Самый тяжелый и проблемный модуль почти всегда сидит перед монитором...

+100

Аватар пользователя glu2006 glu2006 24 сентября 2010 в 12:25

xxandeadxx wrote:
жесть какая-то

Попал в неудачное время, у меня нормально отображается :), может ты по диалапу коннектишься Wink

Аватар пользователя glu2006 glu2006 24 сентября 2010 в 12:58

romashasuper wrote:
1.shared hosting
2.тяжесть - нагрузка на сервер, количество запросов к бд.

Что шаред хостинг? у меня на шареде есть проектик в котором много всего (ну панелей нету да они там и не надо) http://poroxa.net он конечно не блещет великой посещаемостью, но ресурсу всего 7 месяцев.
Если Вы думаете что вьюсы создают нагрузку на сервер по запросам в БД то вперед учить мат часть. Филдовая вьюха выгребает инфу 1 селектом.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 24 сентября 2010 в 12:55

"romashasuper" wrote:
1.shared hosting
2.тяжесть - нагрузка на сервер, количество запросов к бд.

Ичо?
Скальпель может убить, а может принести прибыль. Тут не в модулях вопрос, а в том как ты их используешь

Аватар пользователя Sinkora Sinkora 10 октября 2010 в 19:33

ТС, да не слушай ты этих умников, которые говорят, что Вьюс не является тяжелым модулем.

Страница созданная на Вьюс, например, в полтора раза больше расходует оперативной памяти. А про негибкость Вьюсов я вообще промолчу. Большинство сложных задач в принципе НЕВОЗМОЖНО решать с помощью Вьюсов!

Еще, по моему мнению, тяжелыми/нерациональными являются следующие модули:

  1. Comments
  2. CCK
  3. Forum
  4. Blog
  5. Menu
  6. Statistics
  7. Taxonomy
  8. Tracker
  9. Profile
  10. Search
  11. И т.д.
Аватар пользователя glu2006 glu2006 11 октября 2010 в 9:16

Sinkora wrote:
ТС, да не слушай ты этих умников, которые говорят, что Вьюс не является тяжелым модулем.
Страница созданная на Вьюс, например, в полтора раза больше расходует оперативной памяти. А про негибкость Вьюсов я вообще промолчу. Большинство сложных задач в принципе НЕВОЗМОЖНО решать с помощью Вьюсов!

Если Вьюсы не гибкие, то тогда что-же гибкое в друпале?
Твой собственный запрос в БД?
перефразирую твой ответ: "Большинство сложных задач в принципе ВОЗМОЖНО и НУЖНО решать с помощью Вьюсов!"

Sinkora wrote:
Страница созданная на Вьюс, например, в полтора раза больше расходует оперативной памяти.

Пример в студию, потом будем общаться.

Аватар пользователя Stan.Ezersky Stan.Ezersky 11 октября 2010 в 14:01

Для главного умника, лезем на страницу модулей Drupal.org, где они сортируются по популярности и количеству скачиваний и видим, что первым стоит, как ни странно, Views. Это чём-нибудь говорит?

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 11 октября 2010 в 14:06

"Stan.Ezersky" wrote:
Это чём-нибудь говорит?

Миллионы мух не могут ошибаться, он гений, он превзошёл своё время, он слишком умен для нынешних времён, а вы отказываетесь это принимать!

Аватар пользователя Valeratal Valeratal 11 октября 2010 в 14:17
Еще, по моему мнению, тяжелыми/нерациональными являются следующие модули:

   1. Comments
   2. CCK
   3. Forum
   4. Blog
   5. Menu
   6. Statistics
   7. Taxonomy
   8. Tracker
   9. Profile
  10. Search
  11. И т.д.

чуть чаем не поперхнулся Smile

зачем друпал если нет этих модулей

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 11 октября 2010 в 14:32

"xxandeadxx" wrote:
чтобы синкора за 20$/час написал их тебе ;)

Акуеть! Профессиональный программист прочитавший Вандюка и всего 20 баксов в час, не ценит он себя, ой не ценит...

Аватар пользователя Crea Crea 11 октября 2010 в 14:41

А я бы хотел услышать от Синкоры конкретный пример сложной задачи на тему

Quote:
А про негибкость Вьюсов я вообще промолчу. Большинство сложных задач в принципе НЕВОЗМОЖНО решать с помощью Вьюсов!

Аватар пользователя Stan.Ezersky Stan.Ezersky 11 октября 2010 в 14:46

"xxandeadxx" wrote:
синкора за 20$/час
О, Великий гуру? Обычно больше суммы берут, кроме как за профессиональные навыки, ещё и за репутацию, «бренд». Sinkora раскрученный разработчик и отличный специалист? Стоит ли доверять человеку, который сделал единственный сайт и советует всем лезть в ядро и переписывать готовые модули на свой лад? Не смешно, право-))

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 11 октября 2010 в 14:50

"Stan.Ezersky" wrote:
О, Великий гуру? Обычно больше суммы берут, кроме как за профессиональные навыки, ещё и за репутацию, «бренд». Sinkora раскрученный разработчик и отличный специалист? Стоит ли доверять человеку, который сделал единственный сайт и советует всем лезть в ядро и переписывать готовые модули на свой лад? Не смешно, право-))

Да кто ты такой, по сравнению с SINKORA?
Ты Вандюка читал, чтоб так говорить?

Аватар пользователя Sinkora Sinkora 11 октября 2010 в 21:58

"glu2006" wrote:
Пример в студию, потом будем общаться.

Мне достаточно своих тестов.

"Stan.Ezersky" wrote:

Для главного умника, лезем на страницу модулей Drupal.org, где они сортируются по популярности и количеству скачиваний и видим, что первым стоит, как ни странно, Views. Это чём-нибудь говорит?

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

ТС попросил перечислить тяжелые модули. А ему в ответ заявки типа "какой у тебя хостинг?", "а ведь Вьюсы самые популярные!"... Какая разница какой у него хостинг? Какое дело до популярности модулей? Тема форума о другом.

"Stan.Ezersky" wrote:
Стоит ли доверять человеку, который сделал единственный сайт и советует всем лезть в ядро и переписывать готовые модули на свой лад?

Станислав Езерский, я тебя не знаю, ты меня не знаешь. Смысл делать необоснованные выводы о том, чего мы не знаем на самом деле? Да и услуги свои я никому не предлагаю, нет такой необходимости.

"RxB" wrote:
Ты Вандюка читал, чтоб так говорить?

Вандюк, Вандюк... Знал бы он, как его боготворит Виктор RxB!

Аватар пользователя glu2006 glu2006 12 октября 2010 в 13:01

Sinkora wrote:
Мне достаточно своих тестов.

Нет уж сударь, сказали "А", говорите и "Б"
Пример тормознутости в студию, в противном случае все Ваши высказывания по поводу вьюсов бред и ничего не стоят.

Я повторял, повторяю и буду повторять для организации выборок информации на сайте использовать только "вьюс" и уже если совсем неразрешимая задача (я за 3,5 года работы с друпалом такой не встречал) то попробовать прицепиться к вьюсовому запросу на хуке (признаюсь честно не помню как называется, но 100% знаю что можно) и уж если и это не помогает то писать свое.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 11 октября 2010 в 22:09

"Sinkora" wrote:
Вандюк, Вандюк... Знал бы он, как его боготворит Виктор RxB!

"Sinkora" wrote:
Приветствую, Neochief! Читал многие твои статьи здесь и на других сайтах. Твой энтузиазм, наверное, не только меня одного заставил полюбить Друпал. Я тоже надеюсь, что популярность Друпала будет продолжать расти с каждым днем.

Из перечисленных тобою базовых пунктов у меня пробелы только в следующем:

* Как работать с SVN и CVS? (пока еще не было необходимости)

* Как создавать и применять патчи? (представляю, но пока не пользовался)

* Как реализовывать unit-тесты в Друпале?

А в остальных пунктах ориентируюсь вполне))). Согласен, что книга Джона Вандюка - это первое, что необходимо приобрести начинающему разработчику. Именно эта книга дала мне необходимые начальные знания.

Некоторые мои знакомые пробовали изучать Друпал, но потом бросали его, объясняя это тем, что очень долго необходимо с ним разбираться. Но я всячески пытаюсь им доказать, что это интересная и перспективная технология.

Кстати, с тех пор как я стал серьезно изучать Друпал (чем и сейчас занимаюсь), я просто не могу смотреть теперь на самописные движки сайтов. Ибо любая самописная CMS - трехколесный велик по сравнению с Друпалом.

Друпал рулит по-любому!

Аватар пользователя Sinkora Sinkora 11 октября 2010 в 22:20

"RxB" wrote:

Ичо?

Уже третий или пятый раз приводишь эту цитату... XD

Ну не было у меня еще необходимости реализовывать unit-тесты в Друпале! И что с этого?

А чем плох мой совет новичкам Друпала по поводу чтения книги Вандюка?

Или я еще в чем-то лохонулся, по-твоему? Зачем цитируешь тогда, Вассерманыч ты наш?

Детский сад, хехе...

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 11 октября 2010 в 22:27

Я просто хочу стать таким же гурой как ты, ты оптимизируешь сайты где 10000000000 онлайн (пока нет, но обязательно будет), ты даёшь юзарам советы в стиле "Да тут один простой запрос" и в топик больше не приходишь, ты никогда не приводишь аргументов, думаю это признак высокого профессионализма, жаль что у нас в 10-ом классе нет веб-программирования!

Аватар пользователя Sinkora Sinkora 16 октября 2010 в 12:01

"glu2006" wrote:

Какой пример? Мне достаточно того, что я сам убедился в том, что вьюсы мне не нужны. Я, в принципе, никому не навязываю свою точку зрения.

Мне вот интересно, каким образом будете организовывать логику кеширования на сайте, повсеместно используя вьюсы?

Аватар пользователя Crea Crea 16 октября 2010 в 14:01

Sinkora wrote:
"glu2006" wrote:

Какой пример? Мне достаточно того, что я сам убедился в том, что вьюсы мне не нужны. Я, в принципе, никому не навязываю свою точку зрения.

Мне вот интересно, каким образом будете организовывать логику кеширования на сайте, повсеместно используя вьюсы?

Синкора, как всегда, не в теме
У Views вообще то есть плагины для кеширования и всегда можно написать свой собственный

Аватар пользователя Sinkora Sinkora 16 октября 2010 в 14:28

"Crea" wrote:
У Views вообще то есть плагины для кеширования и всегда можно написать свой собственный

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

Аватар пользователя Crea Crea 17 октября 2010 в 13:52

Sinkora wrote:
"Crea" wrote:
У Views вообще то есть плагины для кеширования и всегда можно написать свой собственный

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

Комментарий в стиле "не играй в мои игрушки и не писай в мой горшок.". Детский сад, штаны на лямках.
Ты не думаешь, что это ты здесь на сайте "писаешь в чужой горшок" ? ))

Аватар пользователя Sinkora Sinkora 17 октября 2010 в 14:25

"Crea" wrote:

Я думаю, что в твоей голове на данный момент ничего нет, кроме эмоций. Поэтому общайся с такими умниками как ты, или с самим собой!

Аватар пользователя glu2006 glu2006 17 октября 2010 в 16:51

Sinkora wrote:
Я думаю, что в твоей голове на данный момент ничего нет, кроме эмоций. Поэтому общайся с такими умниками как ты, или с самим собой!

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

И вот эти тесты и расставят все на свои места, если принимаешь вызов о великий то называй любой хостинг, я думаю что товарищи из "патрола"(RxB, gor) даже предоставят на 2-3 часа этот хостинг с парочкой доменов, ты же успеешь за 3 часа написать запросы для вывода статей ;).

В общем сударь, если не сцыте то выходите на дуэль, секундантами приглашаются все желающие.

Аватар пользователя glu2006 glu2006 17 октября 2010 в 22:22

Sinkora wrote:
А не жалко ли вам времени, господа?

Три часа чтоб доказать преимущество вьюсов перед Вашим сударь самописом мне не жалко, я не обеднею на 45 долларов Wink
Называйте время и место.

Аватар пользователя Sinkora Sinkora 17 октября 2010 в 23:57

"glu2006" wrote:

Ну а вот у меня нет времени на бессмысленные споры и доказательства.

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

Аватар пользователя glu2006 glu2006 18 октября 2010 в 6:36

Sinkora wrote:
Ну а вот у меня нет времени на бессмысленные споры и доказательства.
Но если есть такое желание, можете просто привести здесь весь код, который выполняют Вьюсы во время генерации самой простой страницы. Думаю, результат очевиден - Вьюсы проиграют в любом случае...

В общем сударь все с Вами ясно, диагноз "пустозвон".
Не буду объяснять почему и как, оставайтесь при своем мнении, только не надо молодежи его рассказывать просто держите свое мнение при себе.

PS. не знаю сколько бы тебе потребовалось времени на самопис, я рисковал потерять не более 30 минут для решения своей задачи.
Приведите пример своего самого простого самописа, ведь наработок то уже много для "мега проекта", наверняка есть и выборка и вывод информации.

Аватар пользователя Sinkora Sinkora 19 октября 2010 в 1:59

Простецкий пример, придумал сходу:

<?php

function my_module_menu() {
  $items['test'] = array(
    'title' => 'Test page',
    'page callback' => '_my_module_test',
    'access callback'  => 'user_is_logged_in',
  );

  return $items;
}
function _my_module_test($argument = 10) {
  $nodes = db_query_range('SELECT title FROM {node}', 0, $argument);

  $list = array();
  $output = '';
  $argument_i = $argument;
 
  while ($node = db_fetch_object($nodes)) {
    $list[] = array(check_plain($node->title));
    $argument--;
    $output .= _my_module_test($argument);
  }

  if ($list) {
    if ($argument_i == 1) {
      $output .= theme('item_list', $list);
    }  
    else {
      $output .= theme('table', $headers = array(), $list);
    }
  }

  return $output;
}

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

Аватар пользователя glu2006 glu2006 19 октября 2010 в 9:53

Sinkora wrote:
Простецкий пример, придумал сходу:

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

Не совсем понял зачем там рекурсия, что это за чудо вывод информации, если Вам надо вытащить 10 node->title или каким либо образом их сгруппировать, то:
Обыкновенный филдовый вьюс 1й филд node->title, 2-й филд по какому признаку группировать. Далее выбираете себе стиль отображения филдовый или табличный или еще какой нибудь и все.

А логика там проста до безобразия 1 запрос в БД и обработка данных (разматывание выборки), затем подготовка данных на препроцесс функции и вывод через шаблон.
Теперь плюсы: можно прицепится к обработке и выводу контента практически на любом этапе не ломая при этом код самих вьюсов, в Вашем примере этого нет вы даже не удосужились согласно правил кодирования разнести в разные функции вычитку с обработкой и вывод готового html, что уже мне сказало о многом.
+2 кеш как на уровне вьюсов так и на уровне ядра друпала, у Вас этого нет.
+3 если я к примеру захочу тут же сделать поиск по тайтлу, то мне достаточно просто добавить и раскрыть фильтр по contains а Вам придется переписывать свой запрос. А не дай бог туда еще и аякс засунуть а я просто поставлю галочку.
+4 я завтра захочу поменять вывод таблицей на вывод списком или дивами, Вы опять курите нервно в стороне а я всего лишь переключаю радиобаттон.
+5 я нажав всего одну кнопку организую вывод этой информации в любой регион на сайте а вы опять нервно курите и пихаете в блок вызов функции.
+6 в конце концов мне не надо писать ни строчки кода, только если перекрыть шаблон вывода, а Вам надо регистрировать хук меню, сбрасывать кеш, не забыть про пермишены и самое главное не забыть о пунктуации и орфоргафии php не дай бог ; забудете поставить где нибудь.
и если хорошо подумать то таких плюсов моего метода я смогу Вам привести еще столько-же.

Да а вот если Вы захотите реализовать самописькой задачу которую Вам куку выкатил то там я вообще посмеюсь.

Да, чуть не забыл вы в своем примере количество запросов в БД посчитали? Wink

Аватар пользователя kyky kyky 19 октября 2010 в 2:16

"Sinkora" wrote:
Простецкий пример, придумал сходу:

Вот именно, что простецкий, банальности расписывать ума не надо. Ты лучше реализуй пример с отбором нод типа "квартира/машина" по динамическим фильтрам.
У каждой ноды 10-15 CCK-полей (чиловые, текстовые, референсы, имейджы), наверху 5 exposed-фильтров, всё через аякс.

Аватар пользователя Sinkora Sinkora 20 октября 2010 в 0:35

"glu2006" wrote:
Не совсем понял зачем там рекурсия

Чтобы попросить сделать вас такой же рекурсивный колбек на Вьюсах:)

Также там есть динамическая смена шаблонов вывода (таблица/список) - как такое на Вьюсах можно сделать?

"glu2006" wrote:
Да, чуть не забыл вы в своем примере количество запросов в БД посчитали? ;)

Да, да, считал, их очень много:) Но на Вьюсах не меньше будет.

Насчет задачи Куку. Надо будет сделать - сделаю.

P.S. А если в настройках Вьюсов не найдется нужной галочки/кнопочки, что будете делать?:)

Аватар пользователя glu2006 glu2006 20 октября 2010 в 9:28

Sinkora wrote:
Чтобы попросить сделать вас такой же рекурсивный колбек на Вьюсах:)
Также там есть динамическая смена шаблонов вывода (таблица/список) - как такое на Вьюсах можно сделать?

Если уж Вам так хочется, то говно вопрос я напишу точно такую же рекурсию на preprocess_view

<?php
function phptemplate_preprocess_views_view_(тип и имя вьюхи)_page_1(&$vars) {
 
$vars['recursion'] = моя рекурсивная theme функция ($vars['view']->result);

}

?>

В шаблоне стиля вьюхи: <?php print $recursion?>

Sinkora wrote:
Да, да, считал, их очень много:) Но на Вьюсах не меньше будет.

У меня 1 запрос Wink + у меня кеширование а у тебя дырка от бублика и гора запросов в БД.

Sinkora wrote:
Насчет задачи Куку. Надо будет сделать - сделаю.

Ты это если и сделаешь в лучшем случае минимум за 5-7 часов (не забудь там пару рекурсивных выводов написать), а я за 1 максимум только тыркая по кнопкам из админки, даже php знать не надо.

Sinkora wrote:
P.S. А если в настройках Вьюсов не найдется нужной галочки/кнопочки, что будете делать?:)

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

А вот теперь сударь попробуйте убедить меня в том что вьюсы говно. Пойми не могут десятки тысяч программистов всего мира ошибаться, вьюс самый популярный модуль друпала.
Для меня лично без вьюсов и CCK друпал унылое говно, а вот с этими двумя модулями он превращается в мощнейшую систему управления контентом.

PS. Я для себя лично сделал вывод, как программист вы пока еще слишком молоды (иначе и у себя обошлись бы одним запросом), я представляю сколько овно чудо кода в Вашем мегапроекте который к сожалению так никто и не видел.
А по сему спор с Вами прекращаю в виду его дальнейшего бессмыслия, удачи в прочтениях Ван Дюка (как совет перечитайте его в оригинале и лучше раза 2 или три) и остальных авторов. Удачи в изучении друпала и научитесь признавать свои ошибки и поражения.

Аватар пользователя kodo kodo 20 октября 2010 в 18:20

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

Аватар пользователя Sinkora Sinkora 21 октября 2010 в 0:06

"glu2006" wrote:

Если уж Вам так хочется, то говно вопрос я напишу точно такую же рекурсию на preprocess_view

<?php
function phptemplate_preprocess_views_view_(тип и имя вьюхи)_page_1(&$vars) {
 $vars['recursion'] = моя рекурсивная theme функция ($vars['view']->result);

}
?>


1. Вы обещали обойтись без кодинга.

2. И где же код Вашей рекурсивной theme функции?

3.

"glu2006" wrote:

я напишу точно такую же рекурсию на preprocess_view(ПЛАГИАТ!)

Понятно, Ваша рекурсивная theme функция будет точной копией моей функции _my_module_test. Тогда, объясните, в чем Вы выиграете, если одновременно настроите Вьюсы и напишете мой код отдельно от Вьюсов?

3. В итоге, в Вашей рекурсивной функции, так же как и в моей, будет 1 запрос. И при рекурсивном вызове он выполнится 1024 раза, не больше и не меньше.

"glu2006" wrote:
У меня 1 запрос Wink + у меня кеширование а у тебя дырка от бублика и гора запросов в БД.

У Вас же моя рекурсивная функция (сами признались), и это значит, что у Вас как минимум 1024 запроса.

Юрий, я разве писал в своем колбеке что-то подобное на функции cashe_set, cashe_get? Ну? Тогда зачем Вы ставили галочку "кешировать"? У меня же условие было без кеширования!

"glu2006" wrote:
Вьюс расширяемый модуль и если нужной галочки не будет, то я сяду и напишу эту нужную мне галочку в виде плагина.

О, опять кодинг на php - но это же нерационально! Вы ведь утверждаете, что на Вьюсах можно делать функционал "только тыркая по кнопкам из админки, даже php знать не надо"...

"glu2006" wrote:
А вот теперь сударь попробуйте убедить меня в том что вьюсы говно. Пойми не могут десятки тысяч программистов всего мира ошибаться, вьюс самый популярный модуль друпала.
Для меня лично без вьюсов и CCK друпал унылое говно, а вот с этими двумя модулями он превращается в мощнейшую систему управления контентом.

Как говорил раньше, я не собираюсь Вас убеждать ни в чем. Это Вы, наоборот, хотите меня убедить, что Вьюсы - это истинный путь Друпал-ниндзи. Но я имею право с Вами не согласиться!

"glu2006" wrote:
PS. Я для себя лично сделал вывод, как программист вы пока еще слишком молоды (иначе и у себя обошлись бы одним запросом), я представляю сколько овно чудо кода в Вашем мегапроекте который к сожалению так никто и не видел.

Юрий, знания и опыт - это хорошее дело. Но более важно уметь эффективно применять эти качества на практике, а не на тестовых примерах.

Насчет одного запроса. Повторюсь, Вы написали, что повторили мою рекурсивную функцию - это значит, что запросов типа "SELECT title FROM node LIMIT 0, (переменная)" у Вас ровно такое же количество (1024)!

И уж очень близко к сердцу Вы приняли мой тестовый пример, в котором акцент делался не на количество запросов, а именно на факт того, что рекурсию и динамическую подстановку функций theme('item_list', $list); и theme('table', $headers = array(), $list); Вы не сможете реализовать на Вьюсах "только тыркая по кнопкам из админки"!

Вы действительно думаете, что это был "рабочий пример", и что я фанатик рекурсивных запросов n-го порядка? Если бы мне нужно было это реализовать одним запросом, то я бы это сделал именно одним запросом, а остальной вывод реализовал бы через массив в рекурсии. Но повторюсь, задача была не в этом.

"glu2006" wrote:
А по сему спор с Вами прекращаю в виду его дальнейшего бессмыслия, удачи в прочтениях Ван Дюка (как совет перечитайте его в оригинале и лучше раза 2 или три) и остальных авторов. Удачи в изучении друпала и научитесь признавать свои ошибки и поражения.

Юрий, Вы так и не решили мою простейшую задачу! Вы прочитали мне целый курс молодого бойца о модуле Вьюс, чего я Вас не просил делать, поскольку базовые знания по этому модулю имею вполне адекватные. И в конечном итоге, не справившись с задачей (если не считать того, что Вы на пальцах прикинули решение), Вы перешли на самое последнее дело - на критику моей личности, гордо уверив себя, xxandeadxx и kodo в своей правоте.

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

А если насчет Вандюка, то в своей книге он о Вьюсах ничего такого и не писал, он вообще про Вьюсы ничего не писал (имею в виду его книги для 5-ки и 6-ки)! И что вообще из моего скромного колбека заставило Вас думать, что я не умею пользоваться API Друпала?

P.S. Юрий, я раньше имел о Вас более лестное представление.

Аватар пользователя glu2006 glu2006 21 октября 2010 в 11:06

Sinkora wrote:
1. Вы обещали обойтись без кодинга.

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

Если Вы помните то Вам предлагалось написать самопис выводящий статьи в определенном виде по определенному урлу при чем тут рекурсия? или вы на своих мега проектах новости тоже рекурсивно выводите?

Sinkora wrote:
2. И где же код Вашей рекурсивной theme функции?

Если Вам так сильно свербит посмотреть на рекурсию пожалуйста:

<?php
function моя_рекурсия($items) {
  
$list = array();
  
$output '';
  
$count count($items);
  foreach (
$items as $key => $item) {
    
$list[] = array(check_plain($item->title));
    unset(
$items[$key];
    
$output .= моя_рекурсия($items);
  }
 
  if (
$list) {
    if (
$count == 1) {
      
$output .= theme('item_list'$list);
    }  
    else {
      
$output .= theme('table'$headers = array(), $list);
    }
  }
  return 
$output;
}
?>

Sinkora wrote:
ПЛАГИАТ!

Ни о каком плагиате речи не идет у меня так и остался 1 запрос в БД, вы еще и в код смотрите сквозь пальцы.
У меня 1 запрос Wink + у меня кеширование а у тебя дырка от бублика и гора запросов в БД.
Sinkora wrote:
Юрий, я разве писал в своем колбеке что-то подобное на функции cashe_set, cashe_get? Ну? Тогда зачем Вы ставили галочку "кешировать"? У меня же условие было без кеширования!

Вы еще и читать внимательно не умеете задача была с кешированием и без.

Sinkora wrote:
О, опять кодинг на php - но это же нерационально! Вы ведь утверждаете, что на Вьюсах можно делать функционал "только тыркая по кнопкам из админки, даже php знать не надо"...

Не надо выдирать мои слова из контекста и пытаться перекрутить на свой лад. Я лишь сказал что функционал для решения задачи предложенной Вам для решения куку можно решить не написав ни строчки кода. Конечно встречаются задачи когда надо вмешаться и в препроцесс и в шаблоны или вообще свою функцию вызвать.

Sinkora wrote:
Как говорил раньше, я не собираюсь Вас убеждать ни в чем. Это Вы, наоборот, хотите меня убедить, что Вьюсы - это истинный путь Друпал-ниндзи. Но я имею право с Вами не согласиться!

Я не пытаюсь не хочу и не буду Вас в чем-то убеждать, потому что вы, как упертый осел доказываете всем что вьюс это плохо и тяжело и что надо писать свои решения и доказываете это в разрез всему сообществу друпала. Вьюс скачивают в неделю 250.000 раз это Вам хоть о чем-то говорит? Или все кругом дураки и только вы такой умный?

Sinkora wrote:
Юрий, знания и опыт - это хорошее дело. Но более важно уметь эффективно применять эти качества на практике, а не на тестовых примерах.

Покажите нам свои эффективно примененные практические знания, мои к примеру есть на друпал орге и на записях выступлений DrupalCamp а где есть ваш опыт??? (это конечно попахивает хвастовством, но реально вы меня вынудили)

Sinkora wrote:
И уж очень близко к сердцу Вы приняли мой тестовый пример, в котором акцент делался не на количество запросов, а именно на факт того, что рекурсию и динамическую подстановку функций theme('item_list', $list); и theme('table', $headers = array(), $list); Вы не сможете реализовать на Вьюсах "только тыркая по кнопкам из админки"!
Вы действительно думаете, что это был "рабочий пример", и что я фанатик рекурсивных запросов n-го порядка? Если бы мне нужно было это реализовать одним запросом, то я бы это сделал именно одним запросом, а остальной вывод реализовал бы через массив в рекурсии. Но повторюсь, задача была не в этом.

Ни куда я ничего не принимал. Пример должен быть логичным, это тоже самое что доказывать нахера друпал для вывода надписи "hello word" пусть даже в рекурсии и со 100 запросами в БД.
Вам предложили задачу, так нет вы нашли свое извращенческое и теперь еще что-то доказываете.

Sinkora wrote:
Юрий, Вы так и не решили мою простейшую задачу! Вы прочитали мне целый курс молодого бойца о модуле Вьюс, чего я Вас не просил делать, поскольку базовые знания по этому модулю имею вполне адекватные. И в конечном итоге, не справившись с задачей (если не считать того, что Вы на пальцах прикинули решение), Вы перешли на самое последнее дело - на критику моей личности, гордо уверив себя, xxandeadxx и kodo в своей правоте.
Если Вы когда-нибудь решите эту детскую задачу, то не поленитесь предоставить нам Вьюсовый экспорт Вашего решения, чтобы мы могли это проверить.
А если насчет Вандюка, то в своей книге он о Вьюсах ничего такого и не писал, он вообще про Вьюсы ничего не писал (имею в виду его книги для 5-ки и 6-ки)! И что вообще из моего скромного колбека заставило Вас думать, что я не умею пользоваться API Друпала?
P.S. Юрий, я раньше имел о Вас более лестное представление.

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

Ну и раз уж тут народ больше трется может кто подскажет решение http://drupal.ru/node/51164 Sinkora нука утри нас всех ;).

Аватар пользователя Sinkora Sinkora 21 октября 2010 в 0:18

"xxandeadxx" wrote:
Sinkora fail

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

"kodo" wrote:
Синкора, вы действительно считаете, что вас просто тут все не любят и обидеть хотят?

Нет я так никогда не считал. Я даже не обижаюсь на Вас за то, что Вы не поняли суть нашего спора с Юрием.

Аватар пользователя glu2006 glu2006 21 октября 2010 в 11:17

Stutzer wrote:
хватит писать Вас и Вы с прописных букв, это хуже, чем ты, ей богу!

http://www.gramota.ru/spravka/letters?rub=rubric_88
Я не претендую на премии, но стараюсь писать грамотно (хотя не всегда получается) Wink

Для тех кому лень по ссылке клацать:
С прописной буквы пишутся местоимения Вы, Ваш как форма выражения вежливости при обращении к одному конкретному лицу в письмах, официальных документах и т. п., напр.: Поздравляем Вас..., Сообщаем Вам...
(Лопатин В. В., Чельцова Л. К., Нечаева И. В.. Прописная или строчная?: Орфографический словарь русского языка. М.: АСТ-ПРЕСС, 1999, 50, стр. 34 ).

Аватар пользователя Stutzer Stutzer 21 октября 2010 в 14:01

Как по мне, Вы и Ваш еще можно простить в рекламных люзоблюдских обращениях к самым ценным клиентам на свете, или при обращении к ну очень уважаемым людям. Но при общении на форуме это скорее подчеркивает дистанцированность собеседника.
Подтверждение своему мнению встречал на многих переводческих форумах, в правилах перевода. Ну и здесь, например, простите за ссылку на самизнаетекого

Аватар пользователя glu2006 glu2006 21 октября 2010 в 14:35

Stutzer wrote:
Как по мне, Вы и Ваш еще можно простить в рекламных люзоблюдских обращениях к самым ценным клиентам на свете, или при обращении к ну очень уважаемым людям. Но при общении на форуме это скорее подчеркивает дистанцированность собеседника.
Подтверждение своему мнению встречал на многих переводческих форумах, в правилах перевода. Ну и здесь, например, простите за ссылку на самизнаетекого

А я к Sinkora в друзья и не набиваюсь Smile
Просто "тыкать" я не приучен поскольку водку или пиго с ним на брудершафт не пил и в одной команде не работал, а писать при обращении к конкретному лицу "вы" с маленькой буквы не получается мизинец автоматом "shift" нажимает.
Так что как говорится такова селяви.

Аватар пользователя shp@drupal.org shp@drupal.org 30 октября 2010 в 3:04

"Crea" wrote:
У Views вообще то есть плагины для кеширования и всегда можно написать свой собственный

Так, а где об этом в документации написано? Smile А то я что-то не нашел...

По поводу спора "Sinkora vs все остальные" - решил провести свое маленькое исследование Smile Итак, страница, реализованная с помощью views, отрабатывает примерно за 1.1-1.3 сек, с включенным кэшированием Rendered output - примерно 0.6 сек. То же самое с помощью своего кода (pager_query(), node_view(), theme('pager')) БЕЗ всякого кэширования - ~0.7 сек (+ при когда отключим сам views, доп. выиграем на загрузке модулей в bootstrap, но это я уже не смотрел). Т.е. по времени генерации вроде бы можно добиться с помощью views примерно той же производительности, что и у кастомного кода (правда, во views для этого уже придется включить кэширование). Потребление памяти не смотрел, но здесь наверняка views проиграет.

Теперь подумаем, как можно дальше оптимизировать оба варианта. Свой код - никаких проблем: например, кэшируем каждую отрендеренную ноду, т.е. вместо вызова node_view() будем брать из кэша. А как с views? Не патчить же?

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

Посему очень была бы полезна инфа по плагинам кэширования для вьюс Smile

Аватар пользователя glu2006 glu2006 30 октября 2010 в 10:31

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:
"Crea" wrote:
У Views вообще то есть плагины для кеширования и всегда можно написать свой собственный

Так, а где об этом в документации написано? Smile А то я что-то не нашел...

По поводу спора "Sinkora vs все остальные" - решил провести свое маленькое исследование Smile Итак, страница, реализованная с помощью views, отрабатывает примерно за 1.1-1.3 сек, с включенным кэшированием Rendered output - примерно 0.6 сек. То же самое с помощью своего кода (pager_query(), node_view(), theme('pager')) БЕЗ всякого кэширования - ~0.7 сек (+ при когда отключим сам views, доп. выиграем на загрузке модулей в bootstrap, но это я уже не смотрел). Т.е. по времени генерации вроде бы можно добиться с помощью views примерно той же производительности, что и у кастомного кода (правда, во views для этого уже придется включить кэширование). Потребление памяти не смотрел, но здесь наверняка views проиграет.

Теперь подумаем, как можно дальше оптимизировать оба варианта. Свой код - никаких проблем: например, кэшируем каждую отрендеренную ноду, т.е. вместо вызова node_view() будем брать из кэша. А как с views? Не патчить же?

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

Посему очень была бы полезна инфа по плагинам кэширования для вьюс :)


Товаристч Smile для того чтоб вьюсы работали быстрее необходимо использовать филдовый вьюс этим вы сэкономите туеву кучу запросов.
Во вторых никто не мешает вам включить общий кеш и тогда все ноды тоже бедет кешироваться в таблице cache_content

Аватар пользователя Crea Crea 31 октября 2010 в 18:41

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:
"Crea" wrote:
У Views вообще то есть плагины для кеширования и всегда можно написать свой собственный

Так, а где об этом в документации написано? Smile А то я что-то не нашел...

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

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:
Потребление памяти не смотрел, но здесь наверняка views проиграет.

Есесно. Речь о том, что за счет больших ресурсов мы получаем отличную гибкость, модульность, расширяемость. А проблему ресурсов нужно решать лучшим железом - оно дешевле, чем труд программиста, пишущего свой велосипед вместо views.

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:

Теперь подумаем, как можно дальше оптимизировать оба варианта. Свой код - никаких проблем: например, кэшируем каждую отрендеренную ноду, т.е. вместо вызова node_view() будем брать из кэша. А как с views? Не патчить же?

Помимо плагина для кеширования, можно написать свой display plugin, который будет выводить то что нужно, и как нужно. Патчить ничего не надо.

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:

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

О чем и речь.

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:
Посему очень была бы полезна инфа по плагинам кэширования для вьюс :)

Это open source, читайте исходники (плагина time based cache) и поймете. Не обязательно иметь для этого книжку.

Аватар пользователя Dan Dan 30 октября 2010 в 10:59

Программист должен знать и уметь пользоваться разными инструментами. Он должен знать их сильные и слабые стороны, для того чтобы применять (или не применять) их наиболее эффективно.
Программер умеющий кодить и знающий две-три библиотеки будет подуктивнее программиста, который просто кодит. Думаю это вполне очевидно.
Споры про тяжесть вьюс идут давно, однако противники вьюс, как показывает практика, плохо знают как он работает, плюс пишут свой код достаточно криво. На предложение "посоревноваться" всегда отвечают "мне некогда". Показательно.
Однако. Views не может быть легче самописного модуля из трёх строк, т.к. он работает по всем правилам Drupal (которые очень любят игнорировать начинающие друпалисты): вызывает перед и после каждого своего действия опрос хуков, которые могут изменить его поведение, выводит все данные через слой темизации с шаблонами и препроцессингом и тд. и т.п. Спору нет "print $title;" будет быстрее работать, вот только писать вы его будете на порядок (если не больше!) дольше.

Аватар пользователя shp@drupal.org shp@drupal.org 30 октября 2010 в 19:01

"glu2006" wrote:
Товаристч Smile для того чтоб вьюсы работали быстрее необходимо использовать филдовый вьюс этим вы сэкономите туеву кучу запросов.

1. Допустим, мне нужны обычные тизеры нод, и я хочу использовать "филдовый вьюс" - в этом случае придется темизировать вывод рез-тов, чтобы они выглядели как тизеры нод? По-моему, такое дублирование темизации несколько кривовато.

2. Даже если это меня устроит, рендеринг такого вью - около 0.4 сек (с включенным кэшированием вью). Тоже не фонтан.

"glu2006" wrote:
Во вторых никто не мешает вам включить общий кеш и тогда все ноды тоже бедет кешироваться в таблице cache_content
Вы невнимательно читали, я пробовал и с кэшем вьюс, и без.

Аватар пользователя glu2006 glu2006 31 октября 2010 в 0:03

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:
1. Допустим, мне нужны обычные тизеры нод, и я хочу использовать "филдовый вьюс" - в этом случае придется темизировать вывод рез-тов, чтобы они выглядели как тизеры нод? По-моему, такое дублирование темизации несколько кривовато.
2. Даже если это меня устроит, рендеринг такого вью - около 0.4 сек (с включенным кэшированием вью). Тоже не фонтан.
Вы невнимательно читали, я пробовал и с кэшем вьюс, и без.

Для того чтоб у вас не было проблем не используйте стандартное поле body оно еще с 4.7 кривое и корявое, сделайте свой сск филд и будет фонтан.
Блин ну почему не стараетесь мыслить на перед???
Все проблемы производительности друпала из-за незнания элементарных вещей.
Вы к примеру знаете что установленный модуль advansed_forum увеличивает время генерации страницы в 10 раз(из-за не проиндексированного tid), всего лишь один индекс в БД по tid который не предусмотрен по умолчанию и его надо просто ручками указать уменьшает это же время в те же 10 раз Smile
Прикольно не правда ли;)

надо всего лишь избегать node_load и вьюсы будут летать.

Аватар пользователя shp@drupal.org shp@drupal.org 30 октября 2010 в 19:06

"Dan" wrote:
Это все понятно, я с вами полностью согласен. Но я, вообще-то, и не являюсь ярым противником вьюс, если вы не заметили. Я за объективность (поэтому и привел конкретные цифры). Я скорее думаю, как вьюс можно оптимизировать, т.к. его функциональность не очень хочется реализовывать "ручками" Smile

Аватар пользователя shp@drupal.org shp@drupal.org 30 октября 2010 в 19:09

"RxB" wrote:
Нет, домашний комп, довольно старый (SocketA Athlon 1.7, DDR1 512 Mb и т.д.). Можно и на реальном хостинге протестировать, не вопрос.

Аватар пользователя Dan Dan 31 октября 2010 в 0:56

"glu2006" wrote:
Для того чтоб у вас не было проблем не используйте стандартное поле body оно еще с 4.7 кривое и корявое, сделайте свой сск филд и будет фонтан.

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

Аватар пользователя glu2006 glu2006 31 октября 2010 в 7:28

Dan wrote:
Вьюсы криво режут поля. Пару раз надо было резать по словам - обрезалось магически криво с разницей в пару предложений и посреди слова, хотя "округление" стояло пословное. Делал руками. В 3-й версии не проверял. В 7-ке текстовое поле доделали и оно теперь может быть "тизерным".

Я если честно ни разу не встречал чтоб вьюсы что-то криво резали в сск, там выполняется на пост обработке точно такой же truncate_utf8 как и вызванный руками.
А вот с боди там иногда творятся чудеса.

Аватар пользователя Valeratal Valeratal 31 октября 2010 в 8:47

вот, на встречер, говорил
что стандартный форум кривой в плане производительности
а вот advansed_forum получше

кстати, tid это поле к чему?

Аватар пользователя Dan Dan 31 октября 2010 в 10:05

"glu2006" wrote:
Я если честно ни разу не встречал чтоб вьюсы что-то криво резали в сск, там выполняется на пост обработке точно такой же truncate_utf8 как и вызванный руками.

Ну дык, это-то и странно. Дебажить было лень, поэтому не разбирался, однако факт. Мало того, резало ещё и не по utf, а по ansi, то есть возникали "вопросики" что совсем уже ни в какие ворота. Другими словами как-то там до truncate_utf8 не доходило...

Аватар пользователя shp@drupal.org shp@drupal.org 31 октября 2010 в 18:16

"glu2006" wrote:
Вы к примеру знаете что установленный модуль advansed_forum
Ну в обсуждаемой ситуации с вьюс проблем с организацией БД пока вроде не наблюдается... И, кстати, advanCed_forum

"glu2006" wrote:
надо всего лишь избегать node_load и вьюсы будут летать.
Наверное, вы будете удивлены, но даже при использовании "филдового" вью может вызываться node_load() Smile Пример - вывод уберкартовской цены.

И еще раз повторяю - филдовый вьюс не всегда подходит, т.к. для получения обычных тизеров нод придется темизировать вывод вью, причем дублировать разметку из node.tpl.php, что не есть хорошо. Гораздо логичнее сначала попытаться оптимизировать модуль views вообще.

Что касается кэширования views, тут тоже есть небольшая проблемка. Кэш Rendered output не сбрассывается при обновлении нод, причем ручной сброс через Tools модуля views тоже не помогает - только сброс всех друпаловских кэшей (раздел Производительность). Не спорю - можно сделать сброс этого кэша самому (hook_nodeapi()) - но сам факт. А кэш только Query results производительность не улучшает.

Аватар пользователя shp@drupal.org shp@drupal.org 31 октября 2010 в 19:06

"Crea" wrote:
Помимо плагина для кеширования, можно написать свой display plugin, который будет выводить то что нужно, и как нужно.
Вот это полезно, спасибо. Я просто views раньше особо не изучал, поэтому в его структуре пока ориентируюсь слабо.

Аватар пользователя shp@drupal.org shp@drupal.org 4 ноября 2010 в 22:16

Я все-таки не пожалел времени и устроил сравнение "Views vs. Custom code" Smile Спасибо в т.ч. it-patrol в лице RxB.

Итак, имеем сразу 2 сборки Друпала с Уберкартом и одинаковым контентом (11 нод типа Product). На обеих сборках реализован постраничный вывод продуктов: на одной - с помощью views, на другой - своим модулем (с поддержкой кэширования).

Результаты тестирования на хостинге it-patrol:

Views, без кэширования, ноды - 0.2 сек, 5 Мб, 147 запросов.
Views, без кэширования, поля - 0.12 сек, 5 Мб, 88 запросов.

Views, с кэшированием, ноды -  0.07 сек, 5 Мб, 49 запросов.
Views, с кэшированием, поля -   0.07 сек, 5 Мб, 49 запросов.

Свой модуль, без кэширования, ноды - см. тест на хостинге-2.
Свой модуль, с кэшированием, ноды -   0.04 сек, 2 Мб, 31 запрос.
Свой модуль, поля - тест не проводился.

* Цифры получались просто - страница вручную обновлялась несколько раз, затем выбирался лучший результат. Расход памяти был получен с помощью memory_get_peak_usage(). Кэширование во Views - Rendered output.

Результаты тестирования еще на одном хостинге:

Views, без кэширования, ноды - 0.3 сек, 12 Мб, 147 запросов.
Views, без кэширования, поля - тест не проводился.

Views, с кэшированием, ноды -   0.22 сек, 12 Мб, 49 запросов.
Views, с кэшированием, поля - тест не проводился.

Свой модуль, без кэширования, ноды - 0.21 сек, 9 Мб, 92 запроса.
Свой модуль, с кэшированием, ноды -   0.16 сек, 9 Мб, 31 запрос.
Свой модуль, поля - тест не проводился.

Мой вывод: по-видимому, на нормальном хостинге абсолютные цифры должны быть приемлемыми для всех вариантов, поэтому лучше использовать views как более гибкое и быстрое в реализации решение.

Если хочется улучшить производительность - попробовать оптимизировать views (см. ниже). Переходить для этого на свой код - выигрыш в абсолютных цифрах получатся небольшим (хоть в относительных и в 1.5-2 раза быстрее), а по гибкости это конечно хуже.

Свой код, похоже, имеет смысл использовать, только если нужно что-то, что нельзя сделать с помощью views.

Правда, если использовать кэширование views, придется писать свой cache-plugin, т.к. в Timebased сброс кэша по изменению нод действительно не предусмотрен (т.е. это не баг). Может кого-то такое кэширование и устраивает, меня - нет. В принципе, там ничего сложного. Ну или, как предлагал Crea, написать сразу display plugin (с этим я как раз сейчас разбираюсь).

Аватар пользователя Dan Dan 4 ноября 2010 в 2:21

Отлично! Спасибо за сравнение.
Пару вопросов: почему в своём модуле не сравнивали с кэшрованием и без? Код модуля желательно тоже прикрепить.

Аватар пользователя glu2006 glu2006 4 ноября 2010 в 9:41

Вьюха которая делает нод лоад не показатель, сделайте филдовую причем с перекрестными запросами, плана node_reference проверьте производительность Smile

Я вообще никогда не использую вьюсы которые делают node_load в них нет смысла поскольку сам по себе node_load кешируемая функция и в этом варианте проще написать свой запрос который выгребет все ниды и потом в цикле размотает.
По поводу node_load для цены уберкарта не ткнете носом где там нод лоад?
если цена в запросе выгребается это кстати вьюха из коробки

SELECT node.nid AS nid,
   node.type AS node_type,
   node.title AS node_title,
   uc_products.sell_price AS uc_products_sell_price,
   node.vid AS node_vid
 FROM node node
 LEFT JOIN uc_products uc_products ON node.vid = uc_products.vid
 WHERE (node.status <> 0) AND (node.type IN ('product','tovars'))
   ORDER BY node_title ASC

и в форматере поля я тоже нод лоад к сожалению не нашел.

А вот когда строится форма с кнопкой, то там нод лоад выполняется поскольку функции theme_uc_product_add_to_cart(); необходим для построения формы объект node, НО если мы включаем модуль UC_Cart_Link, и заменяем кнопку на ссылку нод лоад не выполняется поскольку для линки достаточно просто nid а уж сделать из нее кнопку я думаю особого труда не составит.

Теперь по поводу дублирования кода из node.tpl.php для тизера что как вы выразились не есть хорошо. Расскажите мне что мешает Вам как программисту написать свою theme функцию которая будет принимать определенные параметы и генерить из них нужный html??
На выходе имеем 1 функцию которую вызываем и на node.tpl.php и на шаблоне филдового вьюса (профит).

Аватар пользователя shp@drupal.org shp@drupal.org 4 ноября 2010 в 9:53

"Dan" wrote:
Пару вопросов: почему в своём модуле не сравнивали с кэшрованием и без?

Дело в том, что у меня там кэширование не отключается (это ж не рабочий модуль, а так, для проверки). Вообще, тоже интересно, могу проверить на втором хостинге (к it-patrol доступа по FTP уже нет, хотя сайт еще живой).

Ну и код модуля.

vvc.module:

<?php

define('VVC_NODES_PER_PAGE',    10);
define('VVC_MSG_NO_DATA',       'No data to display!');

/**
 * Implementation of hook_menu().
 */

function vvc_menu() {
 
  $items['products-list'] = array (
    'title' => 'Products list',
    'page callback' => 'vvc_page_products_list',
    'access arguments' => array ('access content'),
    'menu_name' => 'primary-links',
  );
 
  return $items;
}

function vvc_page_products_list() {
  $context = vvc_get_current_context();
 
  // Запрос на выборку опубликованных нод типа Продукт + попытка сразу получить эти ноды из кэша:
  $h_query = pager_query("SELECT n.nid, c.data
                          FROM {node} n
                          LEFT JOIN {cache_vvc_nodes} c  ON n.nid = c.nid AND c.context = %d
                          WHERE n.type = 'product' AND n.status = 1
                          ORDER BY n.sticky DESC, n.created DESC"
,
                          VVC_NODES_PER_PAGE, 0, NULL,
                          $context);
 
  $output = '';
  $are_nodes = FALSE;
 
  while ($row = db_fetch_array($h_query)) {
    // Эта нода есть в кэше:
    if (isset($row['data'])) {
      $output .= $row['data'];
    }
    // Этой ноды нет в кэше. Рендерим эту ноду + добавляем ее в кэш:
    else {
      $node_output = node_view(node_load($row['nid']), TRUE);
      $output .= $node_output;
      db_query("INSERT INTO {cache_vvc_nodes} (`nid`, `context`, `data`)
                VALUES (%d, %d, '%s')"
, $row['nid'], $context, $node_output);
    }
   
    $are_nodes = TRUE;
  }
 
  return $are_nodes ? ($output . theme('pager', NULL, VVC_NODES_PER_PAGE)) : t(VVC_MSG_NO_DATA);
}

/**
 * Implementation of hook_nodeapi().
 */

function vvc_nodeapi($node, $op) {
 
  // Удаляем из кэша все записи для этой ноды:
  switch ($op) {
    case 'delete':
    case 'insert':
    case 'update':
      db_query("DELETE FROM {cache_vvc_nodes}  WHERE nid = %d", $node->nid);
  }
}

/**
 * Implementation of hook_flush_caches().
 */

function vvc_flush_caches() {
  return array ('cache_vvc_nodes');
}

/**
 * Возвращает текущий контекст (для разных контекстов ноды могут иметь различный вид, например, из-за прав юзеров)
 */

function vvc_get_current_context() {
  global $user;
 
  // Не будем усложнять Smile
  return $user->uid ? 1 : 0;
}

vvc.install:

<?php

/**
 * Implementation of hook_install().
 */

function vvc_install() {
  drupal_install_schema('vvc');
}

/**
 * Implementation of hook_uninstall().
 */

function vvc_uninstall() {
  drupal_uninstall_schema('vvc');
}

/**
 * Implementation of hook_enable().
 */

function vvc_enable() {
  // Очищаем весь кэш:
  db_query("DELETE FROM {cache_vvc_nodes}");
}

/**
 * Implementation of hook_schema().
 */

function vvc_schema() {
 
  $schema['cache_vvc_nodes'] = array (
    'fields' => array (
      'id' => array (
        'type' => 'serial',
        'unsigned' => TRUE,
        'not null' => TRUE),
      'nid' => array (
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE),
      'context' => array (
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0),
      'data' => array(
        'type' => 'text',
        'not null' => TRUE,
        'size' => 'medium'),
    ),
    'primary key' => array ('id'),
    'indexes' => array (
      'nid' => array ('nid'),
      'context' => array ('context'),
    ),
  );

  return $schema;
}

vvc.info:

name = Views vs Custom code
description = Test - Views vs Custom code.
core = 6.x
version = "6.x-1.0"

По хорошему, в схеме нужно было бы еще сделать unique key по полям nid и context, но здесь это неактуально Smile

Аватар пользователя shp@drupal.org shp@drupal.org 4 ноября 2010 в 10:51

"glu2006" wrote:
Вьюха которая делает нод лоад не показатель, сделайте филдовую причем с перекрестными запросами, плана node_reference проверьте производительность :)

Филдовую проверял только с timebased-кэшированием, отличия от "нодовой" естественно нет. Дело в том, что я с самого начала ориентировался на то, что буду использовать views с каким-либо кэшированием. Проверю и это на днях.

"glu2006" wrote:
Я вообще никогда не использую вьюсы которые делают node_load в них нет смысла поскольку сам по себе node_load кешируемая функция и в этом варианте проще написать свой запрос который выгребет все ниды и потом в цикле размотает.

node_load() - вообще-то, не единственный тормоз, есть еще node_view(). Поэтому лучше, на мой взгляд, написать нормальное кэширование к views или например display-plugin.

"glu2006" wrote:
Теперь по поводу дублирования кода из node.tpl.php для тизера что как вы выразились не есть хорошо. Расскажите мне что мешает Вам как программисту написать свою theme функцию которая будет принимать определенные параметы и генерить из них нужный html??
На выходе имеем 1 функцию которую вызываем и на node.tpl.php и на шаблоне филдового вьюса (профит).

Если мне нужны тизеры нод, варианты следующие (timebased-кэширование не используем, т.к. в реальности оно мало кому подходит):
1) Использовать "нодовую" view. Без кэширования и каких-либо дописываний.
2) Использовать "филдовую" view. Без кэширования и с дописываниями на уровне темизации, как вы и описали.
3) Использовать view например со своим кэшированием. Поскольку есть кэширование, разницы уже нет - нодовую view использовать или филдовую. Поэтому естественно выбираем первый вариант.

Сравниваем варианты 2 и 3 - и там, и там нужно дописывать свое, но вариант 3 явно будет лучше в плане производительности и перспективности. Итого остаются варианты 1 и 3. Хотя, по трудоемкости реализации кэширование конечно будет сложнее.

Если нужна, например, таблица, тут проще - филдовая view без кэширования, либо она же со своим кэшированием.

"glu2006" wrote:
По поводу node_load для цены уберкарта не ткнете носом где там нод лоад? если цена в запросе выгребается это кстати вьюха из коробки
Нет, это своя вьюха. Где вызывается node_load точно уже не помню, по-моему, все-таки в каком-то форматтере из Уберкарта. Я просто вставил echo в node_load, так и обнаружил, что она вызывается.

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

Вообще, вот тестовый сайт на it-patrol: http://views-or-not-views.atlant.vps-private.net

Аватар пользователя shp@drupal.org shp@drupal.org 4 ноября 2010 в 17:54

Добавил результаты филдовой view (перекрестных запросов, правда, не делал Smile ). glu2006: конечно, производительность лучше, чем у нодовой view (почти в 2 раза), но хуже, чем с кэшированием. Так что остаюсь при своем мнении: если нужны именно тизеры нод, лучше сразу написать кэш, чем подгонять внешний вид строк под вид тизеров.

Аватар пользователя Dan Dan 4 ноября 2010 в 18:15

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

Аватар пользователя shp@drupal.org shp@drupal.org 4 ноября 2010 в 21:34

"Dan" wrote:
Чтобы сравнивать с филдовой вьюхой, надо и свой модуль допиливать.
Да, по-хорошему надо переделать модуль, чтобы он выводил то же, что и вью. Но если и во view, и в модуле будет кэширование, то результаты для модуля как бы уже есть - 0.04 сек, 2 Мб, 31 запрос (какая разница, что кэшировать - тизер, или, допустим, строку таблицы с полями?). Ну и результаты филдовой view с кэшированием есть.

А если будем сравнивать без кэширования - так сразу и не скажешь, что быстрее. Но мне, честно говоря, не сильно интересно это проверять Smile Я лучше займусь допиливанием views.

"Dan" wrote:
вывод тизеров обычно не требуется, а поля - постоянно.
Не факт, это уже кому что надо. Мне, например, сейчас как раз нужны тизеры.

Аватар пользователя Dan Dan 4 ноября 2010 в 22:01

"<a href="mailto:shp@drupal.org">shp@drupal.org</a>" wrote:
Не факт, это уже кому что надо. Мне, например, сейчас как раз нужны тизеры.

Конечно кому как, но мне уже наверное год как не требовались анонсы. Да и неудобно с ними - никакой гибкости.

Аватар пользователя shp@drupal.org shp@drupal.org 4 ноября 2010 в 22:26

"RxB" wrote:
Доступ по ФТП отрублен потому что я в отпуске, отдыхаю малость, но если кто хочет, выделю отдельную площадку
Если несложно временно включить FTP на views-or-not-views.atlant.vps-private.net - было бы хорошо, я бы еще проверил свой модуль без кэширования. А если сложно - то не надо (я его уже на 2-ом хостинге проверил).

Кстати, еще раз обновил цифры (добавил "свой модуль без кэширования", сделал более читабельно).

Аватар пользователя ZanaDLucTyc ZanaDLucTyc 4 ноября 2010 в 22:34

Вспоминается юзер, который с пеной у рта доказывал, что у него IQ то ли 180 то ли 200+. Хоть убейте не помню, где ента нода - удалили что ли? Smile

Аватар пользователя Dan Dan 4 ноября 2010 в 23:00

"Valeratal" wrote:
с анонсами проще
поставил и забыл

Ага, "поставил". Настроил один список, настроил внешний вид тизера. Пошёл настраивать другой список - опа, а там ссылки не нужны или автора надо вывести или... Будешь шаблоны каждый раз корячить?

"Valeratal" wrote:
А вот, вывод полями этих же анонсов, поставил, помучился с темизацией :))

Всё с точностью до наоборот. Вот допустим нужно мне три дисплея с новостями: Страничный (фото, заголовок, дата, раздел, тизер, автор), Блочный1 (заголовок, фото, дата тизер), блочный2 (заголовок).
Views+views_semantic+css - и никаких шаблонов, всё делается быстро и аккуратно. А если грамотно подойти к именованию css-классов, то внешний вид списков будет меняться просто измением css-класса в настройках. Причём сильно меняться.

Аватар пользователя petrovnn petrovnn 7 ноября 2010 в 21:45

"Stan.Ezersky" wrote:
Semantic Views

Какая прелесть!
Как верстальщик,я ненавидел вьюс за то что он выводит немеряное количество левых дивов, которые нужно переопределять шаблонами. Перешел на нодовый вьюс.

Когда дошло дело до производительности, с помощью drupal for Firebug увидел что для каждого тизера вьюсы вызывается по три функции, и среди них node_load(). Для каждого тизера свой набор запросов к базе с выбором полей. Тогда я думал что это врпнципе вьюса так устроена, а оказалось что только для "нодной вьюсы". Короче я рад.

Посему у меня вопрос, как-бы это сделать более очевидным для начинающих друпалеров? А то ведь делают на нодных вьюсах а потом пишут на хабре что мол, г.. ваш друпал. У меня на осознание этого ушло 5 месяцев изучения друпала. Понятно что может я не самый умный из всех кто когда-либо начинал изучать друпал, но все равно такие вещи нужно делать более очевидными в доках я не знаю, или прямо в админке вьюса писать "при включении Row style:материал" вьюс работает дольше, и жрет больше ресурсов".

Аватар пользователя Valeratal Valeratal 7 ноября 2010 в 22:05

спасибо за семантик
и почему, эту семантику по дефолту не запихнули

Девиз друпала : Все Нужно Допиливать

У Дриса российских корней нет случаем? Smile

Аватар пользователя glu2006 glu2006 8 ноября 2010 в 7:59

Sinkora wrote:
Вы как хотите, ребята, а я с Друпала сваливаю окончательно, нечего с ним больше делать...

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

Аватар пользователя Dan Dan 8 ноября 2010 в 2:53

"petrovnn" wrote:
или прямо в админке вьюса писать "при включении Row style:материал" вьюс работает дольше, и жрет больше ресурсов".

Ты не поверишь! Smile
Quote:
Please note that this row style performs a node_load() for every row, and as such can produce a lot of extra queries. Sometimes this is necessary, but it can have a negative impact on your site's performance!

Правда до этой надписи ещё добраться надо. Когда-то она была на виду...

"Sinkora" wrote:
Вы как хотите, ребята, а я с Друпала сваливаю окончательно, нечего с ним больше делать...

Ну наконец-то ты созрел.

Вот, кстати, самый главный аргумент в пользу использования views: даже если бы он был в 10 раз медленнее, чем есть, всё равно надо было бы говорить что он лучший, иначе так и будут плодиться специалисты, думающие, что они пишут быстрый и компактный код.

Аватар пользователя ihappy ihappy 8 ноября 2010 в 4:40

"Stan.Ezersky" wrote:
 Semantic Views

(( почему, ну почему я этот модуль пропустил(
спасибо за модуль.
"Sinkora" wrote:
Вы как хотите, ребята, а я с Друпала сваливаю окончательно, нечего с ним больше делать...

нет, нет, неееееет!!!! останься о свет друпал комъюнити! Спаси нас от тьмы незнания!

Аватар пользователя Crea Crea 8 ноября 2010 в 10:29

Синкора, не уходи, я все прощу.
Кто же нас будет веселить нелепыми рассуждениями о производительности ?

Аватар пользователя petrovnn petrovnn 8 ноября 2010 в 16:12

"Sinkora" wrote:
Вы как хотите, ребята, а я с Друпала сваливаю

Рекомендую Kohana как простой, эффективный фреймворк с быстрым циклом разработки.

Или Yii если хочется супер-производительности (или хочется к ней стремиться), но здесь придется заплатить большую цену за изучение и за разработку каждого приложения. Короче порог вхождения у Yii существенно выше, и я думаю что он оправдан не для одиночек, а для компаний начиная от 10 человек.

Аватар пользователя natbampo natbampo 8 ноября 2010 в 17:21

petrovnn, не подскажешь(если в курсе), а Symphony по сравнению с тобой указанными как по сложности изучения?
(узнал просто что в моем городе есть одна фирма где на симфони работают)

Аватар пользователя Dan Dan 8 ноября 2010 в 17:32

"petrovnn" wrote:
Рекомендую Kohana как простой, эффективный фреймворк с быстрым циклом разработки.

Я думаю он в пивную сваливает, а не на другой движок.

Аватар пользователя petrovnn petrovnn 8 ноября 2010 в 18:43

"natbampo" wrote:
Symphony по сравнению с тобой указанными как по сложности изучения?

Написал небольшой обзор основных фреймворков, т.к. на протяжении полугода плотно изучал эту тему: http://drupal.ru/node/52387

Если где ошибся - поправьте кто в теме.
Материал основывается на анализе доступной в сети информации; небольшого опыта работы с несколькими фреймворками и «своих ощущениях».

Аватар пользователя kodo kodo 22 декабря 2011 в 5:05

"kolias23" wrote:
Ваши мысли...

Если ты считаешь, что так для тебя и твоих проектов лучше - делай. Могу подсказать еще, что в CSS в последней строке в скобках можно не ставить ; - тоже сократит размер CSS Smile

Избыточность наименований есть, но она не критична и скорее необходима.

Для меня лично servis-block несет гораздо меньше информации (да еще скорее я бы ее вообще к БЛОКУ бы отнес, а не строке вьюс), чем "views-row views-row-3 views-row-odd" - причем, views-row и views-row-odd использую постоянно.
"views-field-field-servis-img-fid" против "servis-img" - в первом случае точно понятно, что это отображение отностся к вьюс, а не ноде. Иногда это надо, иногда нет, но...

"kolias23" wrote:
<div class="servis-price"> <p><span>Ціна:</span> 200 грн 1шт</p> </div>

для меня действительно лучше, удобнее и грамотнее
"kolias23" wrote:
<span class="views-field-field-servis-price-value"> <label class="views-label-field-servis-price-value"> Ціна: </label> <span class="field-content">200 грн 1шт</span>   </span>

Вообщем, считаю что именно это место не является проблемным в Друпал, хотя есть знакомые верстальщики, которые приходили в ужас от количества блоков в Друпале Smile

Аватар пользователя glu2006 glu2006 22 декабря 2011 в 11:18

kolias23 wrote:
Я один из них, но меня не пугает верстка, мне нет разницы в названиях классов, меня пугает плохая оптимизация сайта и беспорядок в коде. Насчет удобства views спорить неуместно - полный автомат и скорость решения задач, а плата за удобство - производительность сайта.

К теме:
Для переопределения классов css есть модуль semanticviews, но он полное ...., так как он еще больше увеличивает вес документа.

О сколько раз твердили миру...
Ну не нравится вам дефолт, ну переопределите шаблон вьюхи и будет вам счастье, что из мухи слона делать. По поводу производительности вьюсов, споров уже был вагон, Но как показывает практика "миллионы мух не могут ошибаться" если вьюсы говно, то почему он самый популярный модуль друпала?

Аватар пользователя Crea Crea 22 декабря 2011 в 11:29

kolias23
А теперь посчитайте, сколько вы выиграете после сжатия в gzip. Надеюсь, вам знакома эта технология ? Это первое, что вы должны включать, вместо оптимизации количества тегов, кавычек и прочей чепухи.

Аватар пользователя Dan Dan 25 декабря 2011 в 6:27

"kolias23" wrote:
Вот она истина, Вы правильно заметили о gzip + нужно добавить к этому css кэширование. А если вывод кода не нравится, разработчики предусмотрели и такой вариант, можно переопределить шаблон views.

Измените ник на К.О. - будет круче.

Аватар пользователя Alexei91 Alexei91 31 декабря 2011 в 11:21

RxB, если без флуда.
ЧПУ на проект,где потенциально будет несколько тысяч страниц.
Имеет ли смысл? D7 + обычный pathauto.
Если судить по Drupal.ru и Drupal.org, то скорее нет, чем да.
Или компромисс, статьи на ЧПУ, а топики форума нет.
Хотя на LiveStreet на 1 сайте типа мини-соц. сети ЧПУ стояли,
но там пока юзеров ок. 200.

Аватар пользователя Valeratal Valeratal 2 января 2012 в 15:12

фигней страдаете какой то (это те, кому лишние дивы мешают)
О контенте думайте, о юзабилити, о пользователях.

Аватар пользователя Alexei91 Alexei91 3 января 2012 в 6:21

RxB, спасибо за ответ.
P.S.
Valeratal, по поводу юзабилити. Ваш hr-portal.ru. У меня в FF 9.0.1 на Linux в подвале появляется явно лишний горизонтальный скроллер.

Аватар пользователя Valeratal Valeratal 3 января 2012 в 9:50

"Alexei91" wrote:
У меня в FF 9.0.1 на Linux в подвале появляется явно лишний горизонтальный скроллер.

странно, в вин не вижу. Но, тем не менее, я сейчас делаю новую тему - субтему из AT. Думаю скролл пропадет