Panels - использовать или нет?

Вс, 18/12/2016 - 14:52

Пожалуй, нет ни одного другого модуля под drupal, о котором мнения разработчиков будут так же диаметрально различаться, как о Panels. То, что модуль гибок и функционален, не вызывает сомнений ни у кого, но вот целесообразность его использования многие ставят под вопрос. Я долгое время избегал использования панелей, чтобы не перегружать сайт лишними (как мне казалось) модулями. Старался обходиться блоками, но со временем стал замечать всё больше и больше недостатков и ограничений блочной системы Drupal. Поэтому однажды я решил поглубже разобраться в панелях и понял, что они порой дают неоспоримые преимущества перед любыми другими решениями. Итак, поехали.

Когда нужно использовать Panels

1. Если нужно выводить поле контента в другом регионе, либо вставить блок между полями.

Это можно сделать и без панелей, через views + блоки, но ведь вьюху ещё нужно создать и настроить, а в панелях прямо из коробки доступны панели со всеми отдельными полями контента. Более того, тут будет прирост по быстродействию, т.к. панели используют уже загруженный объект ноды из контекста, а вьюс возьмёт nid из url страницы и полезет за полем в базу.

2. Вывести один блок одновременно в два региона.

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

3. Сделать разный шаблон для разных словарей таксономии.

Если вам нужно выводить блок на страницах терминов одного словаря, а на страницах другого не нужно, то кроме панелей, это ничем не решить. Можно, конечно, сделать костыль - включить пхп-фильтр и задать в конкретных блоках пхп-условие видимости, но php-фильтр лучше не использовать никогда. И вообще, панели работают с таксономией значительно лучше, чем тот же Taxonomy Display. В частности, при использовании Taxonomy Display не работают Ajax Facets.

4. Работа с фасетами

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

5. При наличии в дизайне сайта большого количества разных шаблонов со сложной структурой колонок.

Во-первых, панели позволяют использовать гибкие лэйауты либо легко создавать свои. Есть также модуль Radix Layouts, который сожержит около 30 разных лэйаутов, совместимых с bootstrap. Во-вторых, как было сказано выше, вы можете выводить один блок в разных лэйаутах в разные регионы, что не позволяет делать блочная система. В третьих, при использовании CSS-фреймворков с сетками, вы можете легко задавать панелям нужные классы и id, чтобы выстроить их по сетке.

6. Если нужно выводить на страницу что-то дико кастомное.

Панели используют Ctools API, которое позволяет легко выводить что угодно и как угодно при довольно простом коде. Более того, подобные задачи - одни из самых любимых на собеседовании у многих работодателей, поэтому овладеть этим кун-фу будет в любом случае полезно :)

Когда не нужно использовать Panels

1. Когда у вас на сайте всего три одинаковые страницы и полтора блока.

2. Когда вы не поняли ничего из того, что было написано выше :)

Примечания

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

2. Всё вышесказанное относится к Drupal 7, в восьмой версии функционал панелей сильно урезан, а функционал блоков наоборот - расширен.

И традиционная спам-ссылка на оригинал статьи в моём говноблоге: http://wellsolutions.by/article/panels-ispolzovat-ili-net

3 Спасибо

Комментарии

Аватар пользователя bumble
2 months 6 дней назад bumble #

На главной.

1 Спасибо
Аватар пользователя bumble
2 months 6 дней назад bumble #
gun_dose написал:
Пожалуй, нет ни одного другого модуля под drupal, о котором мнения разработчиков будут так же диаметрально различаться, как о Panels.

Есть:

  • Views
  • Rules
  • DS (хотя он из той же епархии)
  • все объединяющий Commerce
  • UPD - еще всяческие Context, в т.ч. Contextual links (хоть я и сам их постоянно пользую)
  • ..ещевспомнюнапишу

Да, это модули делающие Друпал - Друпалом. Но нужно понимать что их задача - UI.
Часто платой за это является снижение производительности. И при кейсах с оптимизацией - часто, они первые идут в расход.

0 Спасибо
Аватар пользователя gun_dose
2 months 6 дней назад gun_dose #

дс, кстати, так и ниасилил))

0 Спасибо
Аватар пользователя bumble
2 months 6 дней назад bumble #

Те же панели, только для нод (вьюмодов).

По сути, гуя для перетаскивания в "регионы" полей, аля как на странице блоков.

Ну и множество манящих вкусностей, типа:

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

По сути - все круто, я использовал долго. Но когда есть возможность это дело программно пилить - конечно же будет производительнее.

А при необходимости, можно достичь многого используя просто Field Group.

0 Спасибо
Аватар пользователя gun_dose
2 months 6 дней назад gun_dose #

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

0 Спасибо
Аватар пользователя bumble
2 months 6 дней назад bumble #

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

0 Спасибо
Аватар пользователя postgres
2 months 6 дней назад postgres #

Плюс ко всему - Panels взаимодействуют с ctools plugins: главные из которых content type и contexts. и незаменимы для адаптации контента под разные условия запросов: например, для мобильных устройсnв можно выводить контент с облегченным наполнением в одних панелях, а для десктопов - в других, задавая правила в настройках.

0 Спасибо
Аватар пользователя VasyOK
2 months 5 дней назад VasyOK #
postgres написал:
для мобильных устройсnв можно выводить контент с облегченным наполнением в одних панелях, а для десктопов - в других, задавая правила в настройках.

https://www.drupal.org/project/context_breakpoint - регулярно им свожу с ума заказчиков использую на различного рода проектах. Без помощи всяких панелей.

0 Спасибо
Аватар пользователя VasyOK
2 months 6 дней назад VasyOK #

"4. Работа с фасетами"
Например вот сайтик с фасетами http://watches77.ru/casio (сайт просьба не судить он в вечной разработке).
Для чего тут могут понадобиться панели?

0 Спасибо
Аватар пользователя gun_dose
2 months 6 дней назад gun_dose #

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

0 Спасибо
Аватар пользователя goodboy
2 months 6 дней назад goodboy #
gun_dose написал:
1. Если нужно выводить поле контента в другом регионе, либо вставить блок между полями.
Это можно сделать и без панелей, через views + блоки, но ведь вьюху ещё нужно создать и настроить, а в панелях прямо из коробки доступны панели со всеми отдельными полями контента. Более того, тут будет прирост по быстродействию, т.к. панели используют уже загруженный объект ноды из контекста, а вьюс возьмёт nid из url страницы и полезет за полем в базу.

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

gun_dose написал:
2. Вывести один блок одновременно в два региона.

https://www.drupal.org/project/multiblock

gun_dose написал:
3. Сделать разный шаблон для разных словарей таксономии.

https://www.drupal.org/project/block_visibility_vocabulary

Еще есть https://www.drupal.org/project/context

gun_dose написал:
Панели используют Ctools API, которое позволяет легко выводить что угодно и как угодно при довольно простом коде. Более того, подобные задачи - одни из самых любимых на собеседовании у многих работодателей, поэтому овладеть этим кун-фу будет в любом случае полезно :)

Это да, буржуи любят панели.

0 Спасибо
Аватар пользователя gun_dose
2 months 6 дней назад gun_dose #
goodboy написал:
Если не использовать поля во вьюве, а Содержимое (что рекомендуется) - быстродействие будет аналогичным

Речь идёт о выводе как раз одного единственного поля ноды. Читайте внимательнее.

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

0 Спасибо
Аватар пользователя goodboy
2 months 5 дней назад goodboy #

Если одно поле, разницы особой не будет. В общем случае, видимо панели будут побыстрее. Интересно бы посмотреть в цифрах.

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

Я против панелей ничего не имею, просто написал, что задачу можно решить разными способами. Чем и хорош Друпал.

0 Спасибо
Аватар пользователя VasyOK
2 months 5 дней назад VasyOK #
gun_dose написал:
Если делать магазин какого-нибудь строительного инструмента, то фасетов может быть больше сотни и тогда таскать их по странице блоков будет самой адской мукой.

Понимаю аргумент. Надо будет взять заказ на магазин инструмента и попробую :)

Хотя если проблема в том, чтобы не было муки с перестановкой фасетов - их блоки можно сводить в группы. Например этим https://www.drupal.org/project/blockgroup (хотя тоже не особо удобное решение)
https://www.drupal.org/project/block_visibility_groups - может еще это под 8-ку подойдет.

gun_dose написал:
Итого, вы предлагаете поставить несколько модулей, чтобы только не юзать панели?)))

таки да. У панелях реально как-то монстроузный и неинтуитивный интерфейс. Мне реально легче прописать div-ы в tpl.php шаблонах темы (хотя я добровольно так никогда не делаю), чем юзать панели. Ну или я не умею их готовить.

0 Спасибо
Аватар пользователя fairrandir
2 months 5 дней назад fairrandir #

Ну и минусы панелей
1. Отсутствие сквозных блоков. Если задан кастомный заголовок например, то придётся пройтись по всем панелям и поменять вывод.
2. У блоков - не подхватываются классы из модуля block class, например. Да и вообще настройки блока в принципе.
3. Гибкие панели - только для прототипов. Каждая гибкая панель - это отдельный, генерируемый css файл. Ну и конская вложенность. (где-то в глубине 20-ти дивов спряталось маленькое содержимое поля.
Главный для меня плюс панелей - страницы таксономии и кастомные страницы. И юзаю как правило тупой лэйаут без обёрток, с одним регионом.
Второй плюс: мини-панели. Я ими блоки разные в три колонки вывожу, например.

На вкус и цвет фломастеры разные.

0 Спасибо
Аватар пользователя gun_dose
2 months 5 дней назад gun_dose #
VasyOK написал:
таки да. У панелях реально как-то монстроузный и неинтуитивный интерфейс. Мне реально легче прописать div-ы в tpl.php шаблонах темы (хотя я добровольно так никогда не делаю), чем юзать панели. Ну или я не умею их готовить.

Юзать панели для того, чтобы раскинуть контент по регионам - это действительно всё равно, что палить из пушки по воробьям. У панелей фишка в другом - надо тебе затащить дескрипшн термина вниз - взял и затащил мышью. Хочешь картинку из ноды в шапке выводить - взял и вывел. И не надо никаких вьюсов и кодинга - сокращается время на разработку. Если ничего такого не нужно, то и панели не нужны.

fairrandir написал:
1. Отсутствие сквозных блоков. Если задан кастомный заголовок например, то придётся пройтись по всем панелям и поменять вывод.

Согласен - это минус

fairrandir написал:
2. У блоков - не подхватываются классы из модуля block class, например. Да и вообще настройки блока в принципе.

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

fairrandir написал:
3. Гибкие панели - только для прототипов. Каждая гибкая панель - это отдельный, генерируемый css файл. Ну и конская вложенность. (где-то в глубине 20-ти дивов спряталось маленькое содержимое поля.

Гибкие панели не юзал. Лишние обёртки при необходимости убираю в шаблонах.

0 Спасибо
Аватар пользователя fairrandir
2 months 5 дней назад fairrandir #

>> В панелях можно задавать классы любым фрагментам, т.е. при использовании панелей block class вообще не нужен.
Конечно можно. Каждому фрагменту. Какой хочешь. Но это скорее следствие пункта 1 - невозможность сквозных блоков. У меня есть сайт на поддержке, около 40-ка панелей, на 30-ти есть блок, которому надо было класс прописать. Я огорчился.

0 Спасибо
Аватар пользователя VasyOK
2 months 5 дней назад VasyOK #
gun_dose написал:
надо тебе затащить дескрипшн термина вниз - взял и затащил мышью. Хочешь картинку из ноды в шапке выводить - взял и вывел

Ну дескрипшн термина в блок, картинка ноды в шапке - еще блок. Один блок вверх другой вниз. Стили одинаково для этих элемнтов прописывать. Что они в панелях, что нет.
"И не надо никаких вьюсов" - на вьюсах между прочим очень удобно хлебные крошки делать :)

/*Добавлено*/
Конечно - вьюсом. Им же и хлебные крошки более кастомизированней чем всеми модулями крошек.

0 Спасибо
Аватар пользователя gun_dose
2 months 5 дней назад gun_dose #

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

Для крошек есть path breadcrumbs

0 Спасибо
Аватар пользователя bsyomov
2 months 5 дней назад bsyomov #

Использование панелей в подавляющим большинстве случаев, это плата производительностью и потреблением памяти за возможность "Накликать" шаблон.

В статье перечислено немало заблуждений.
1. Тут сложно что-то сказать, зависит от того что где и зачем...
2.Для этого есть context, копии блоков, программное получение блока и вывод его куда угодно.
3.Это прекрасно делается с без панелей. Если речь о шаблоне, можно делать даже простой темизацией.
5.Нужно просто уметь правильно делать тему, использовать фреймворки, и правильно переиспользовать код.
6. Это лучше делать своим модулем. =)

Я оптимизировал довольно немало сайтов. И избавление от панелей, зачастую, даёт ускорение в пару раз и уменьшает использование памяти до 10 раз! Без шуток. Так что подумайте 10-20-30 раз, стоит-ли в вашем случае скорость разработки значительного падения производительности. Например, для магазина время отклика может быть очень критичным, а именно в них я чаще всего эти проклятые панели и встречаю. =)

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

1 Спасибо
Аватар пользователя gun_dose
2 months 5 дней назад gun_dose #

1. Сложно сказать, потому что панели выводят отдельные поля значительно быстрее вьюсов.
2. Контекст не менее монструозен, чем панели. Программное получение блоков хорошо для шапки и подвала, а программный вывод блоков в контентную часть ведёт к необходимости пожизненного технического сопровождения сайта.
3, 5. Простая темизация - это просто отлично, всегда при возможности обхожусь только ей, но когда шаблон имеет вид:

х9 х3
х6 х6
х5 х7
х4 х4 х4
х12

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

Что касатеся того, стоит ли скорость разработки падения производительности - однозначно стоит. Не всегда, но на небольших проектах точно.

Что касается магазинов, то там алгоритм ускорения совсем другой:
0. Перенастроить вьюсы с полей на отрендеренные сущности
1. Использовать поисковой индекс
2. Если Search API DB недостаточно - ставить solr
3. Переделать вывод меню каталога в статику. Очень интересный пункт, особенно в случае всяких мегаменю. Дело в том, что меню не кэшируется, т.к. на каждой странице нужно высчитывать актив трэйл по новой. Наверное, об этом будет мой следующий пост))

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

0 Спасибо
Аватар пользователя bsyomov
2 months 5 дней назад bsyomov #

«0. Перенастроить вьюсы с полей на отрендеренные сущности»
Ну главное не на ноды... =)
Это, кстати, далеко не всегда оптимальное решение, и при его принятии стоит тестировать производительность, и убедиться перед этим, что сервер БД нормально настроен.
1,2 При чём тут поиск вообще?,
3. Интересно будет почитать об этих граблях.

0 Спасибо
Аватар пользователя gun_dose
2 months 5 дней назад gun_dose #

Ээээ, правда не знаешь, зачем поисковый индекс в магазине?

0 Спасибо
Аватар пользователя bsyomov
2 months 4 дня назад bsyomov #

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

0 Спасибо
Аватар пользователя gun_dose
2 months 4 дня назад gun_dose #

Затем, что от индексации ускорение больше, чем якобы тормоза от панелей)))

0 Спасибо
Аватар пользователя bsyomov
2 months 4 дня назад bsyomov #

Индексации чего?
У вас есть страница с панелями, есть та же без них. Один из вариантов работает эффективнее.
Каким боком тут индексация, если это не страница результатов поиска?
Или вы каталог весь предлагаете используя поиск вместо простой выборки про категории показывать, например?
Или у вас в магазине будет только форма поиска и страница с результатами? =)
Или я вообще не понимаю ход вашей мысли. Брр.

0 Спасибо
Аватар пользователя multpix
2 months 4 дня назад multpix #

 search_api
На базе поискового индекса можно делать свои выборки,
простой пользователь сразу и не скажет, что это поиск, для него это каталог с фильтрами и сортировкой.
Работает в разы быстрее привычных выборок (а в случае с solr еще есть плюшки).

Панели тут не причем.

0 Спасибо
Аватар пользователя gun_dose
2 months 4 дня назад gun_dose #

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

ЗЫ: на самом деле ресурсы жрут не панели, а php и mysql , но вы отказ от них почему-то привели в последнюю очередь)))

0 Спасибо
Аватар пользователя bsyomov
2 months 4 дня назад bsyomov #

Не php и mysql, а излишние абстракции, и кривые запросы.

По поводу поискового индекса - если это внешний solr, если существует много фильтров и.т.п., да, это может быть оптимизацией. Но это не самый частый кейс.
При схеме категории-товары, без 100500 важных для фильтрации полей в товаре, реализация на таксономии и views тоже будет быстрой. Если не испортить её парой тройкой слоёв лишних абстракций, конечно...
И таких магазинов, на самом деле, куда больше. Мало того, сложные фильтры часто просто не уместны, и больше пользователей отвлекают от покупок, чем помогают что-то купить.

Кстати, join, и даже несколько сами по себе не так страшны, если есть нужные индексы.

0 Спасибо
Аватар пользователя voviko
2 months 5 дней назад voviko #
bsyomov написал:
Использование панелей в подавляющим большинстве случаев, это плата производительностью и потреблением памяти за возможность "Накликать" шаблон.

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

0 Спасибо
Аватар пользователя bsyomov
2 months 5 дней назад bsyomov #

Панели не заменяют views, и наоборот.
Панели заменяют отчасти темизацию отчасти context. А темизация на шаблонах в разы быстрее, что и не удивительно - создать структуру по заданной программе куда накладнее, чем вставить значения в готовую структуру.
По поводу кеширования - без панелей оно тоже есть, причем масса разных уровней кеширования от views до кеша страниц, и даже boost, на любой вкус. Почему бы им не пользоваться? Тот же буст будет куда эффективнее, если вы можете позволить себе кеширование. =)
Ну и всегда надо помнить о том, что кеш надо перестраивать, о чём многие забывают, а это очень важно...
Кроме того, кеш не всегда применим в принципе.

Ещё раз советую всем тем, кто возражает по поводу быстродействия произвести эксперимент с профайлером и одинаковым функционалом с панелями и без. Это быстро поставит всё на свои места. Devel + xhprof вполне просто ставятся и неплохо работают. Даже с xdeug не придётся разбираться.

1 Спасибо
Аватар пользователя ХулиGUN
2 months 4 дня назад ХулиGUN #
gun_dose написал:
Пожалуй, нет ни одного другого модуля под drupal, о котором мнения разработчиков будут так же диаметрально различаться, как о Panels

Забыл всеми нами любимый пхп-фильтр)))

gun_dose написал:
Во-вторых, в интерфейсе фасеты идут отдельной категорией, не смешиваясь с остальными блоками. Тот, кто делал магазин хотя бы на 20-30 фасетов, должен оценить это преимущество.

Гаварят фасеты уже не в моде. Тренды устремили свои взоры на составные индексы

gun_dose написал:
Итого, вы предлагаете поставить несколько модулей, чтобы только не юзать панели?)))

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

0 Спасибо
Аватар пользователя kuzmich111
1 month 4 недели назад kuzmich111 #

На почти голом друпале стандартные 15 блоков вывел традиционным способом и через Panels. У панелей оверхед 136%, что весьма не приятно. Хотел использовать в качестве п.5, теперь сижу думаю.

1 Спасибо
Blocks
Panels
Аватар пользователя bsyomov
1 month 3 недели назад bsyomov #

Поздравляю. Хоть один здравомыслящий человек решил-таки проверить. =)
Это, кстати, ещё ничего - не такой и большой оверхед. Обычно всё ещё намного хуже, особенно, если начинают везде этими панелями заменять темизацию...
Там бывает и на порядок получается разница.

0 Спасибо
Аватар пользователя sergeybelya
1 month 3 недели назад sergeybelya #

На мой взгляд Panels один из наиболее бесполезных модулей. Для лендингов гораздо удобнее параграфы, а больше панели ни на что не годятся.

0 Спасибо
Аватар пользователя gun_dose
1 month 3 недели назад gun_dose #

Специально же расписал, что к чему, а вам всё лэндинги))

Постараюсь ещё раз резюмировать в двух словах: панели - это не только таскалка квадратиков в админке, но во многих местах хорошая замена вьюсам, а также хорошее их дополнение + инструмент с мощным АПИ.

А для лэндингов лучше параграфы.

0 Спасибо
Аватар пользователя sergeybelya
1 month 3 недели назад sergeybelya #

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

0 Спасибо
Аватар пользователя VasyOK
1 month 3 недели назад VasyOK #

спасибо попробую https://www.drupal.org/project/paragraphs,
а у панелей действительно весомое преимущество, в том что они нужны многим заказчикам.

0 Спасибо
Аватар пользователя Studio VIZA
1 month 3 недели назад Studio VIZA #

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

0 Спасибо
Аватар пользователя Studio VIZA
1 month 3 недели назад Studio VIZA #
VasyOK написал:
у панелей действительно весомое преимущество.

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

VasyOK написал:
в том что они нужны многим заказчикам.

Прямо ходят и просят? я бы сказал - вспоминают с содроганием.

По моему опыту - использование панелей повышает скорость сайта, если они не криво сделаны.

0 Спасибо
Аватар пользователя VasyOK
1 month 3 недели назад VasyOK #

реально во многих объявлениях о работе вижу пункт panels

0 Спасибо
Аватар пользователя bsyomov
1 month 3 недели назад bsyomov #

Что, часто,говорит о том, что заказчикам не стоит выбирать инструменты, с помощью которых будет сделан их сайт.
Ну и следующий, после такого заказа с панелями, у заказчика другой заказ - сделайте что-нибудь, чтобы сайт хотя бы на выделенном сервере не тормозил.
Вот тут то панелям и хана. =)

0 Спасибо
Аватар пользователя sergeybelya
1 month 3 недели назад sergeybelya #

Объявления в основном составляют хрюшки, понахватавшись умных слов у тл-ов.

0 Спасибо
Аватар пользователя gun_dose
1 month 3 недели назад gun_dose #

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

0 Спасибо
Аватар пользователя VasyOK
1 month 3 недели назад VasyOK #

ага хотел в одну нормальную контору устроится, так меня прям порога спросили:
"Скажи мне брат, любишь ли ты панели как люблю их я, а не наплодишь ли ты регионов в теме оформления"

0 Спасибо
Аватар пользователя sergeybelya
1 month 3 недели назад sergeybelya #

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

0 Спасибо
Аватар пользователя VasyOK
1 month 3 недели назад VasyOK #

gun_dose, можешь в теме голосование поставить? Пункты на твое усмотрение, как вариант эти.
Panels это...
1) инструмент разработки универсальных решений (использую везде)
2) инструмент разработки кастомных решений (использую редко)
3) инструмент выбивания денег из забугорых заказчиков (использую потому что платят)
4) неудобный инструмент (не использую вообще)

0 Спасибо
Аватар пользователя gun_dose
1 month 3 недели назад gun_dose #

Опросы глючат. Виснет страница при голосовании.

0 Спасибо
Аватар пользователя bsyomov
1 month 3 недели назад bsyomov #

Забыл ещё вариант:
5) Приходится вырезать на каждом втором оптимизируемом сайте. =)

0 Спасибо
Аватар пользователя gun_dose
1 month 3 недели назад gun_dose #

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

0 Спасибо

Страницы