Оптимизировать компоненты каталога и новостей
- Отказаться от разделения на каталог и новости, и назвать компоненты - "элементы инфоблока", "элемент инфоблока детально" и т.д.
- В настройках компонентов есть логичный параметр - "Свойства", позволяющий выбрать, какие свойства элементов нужно выводить. Они попадают в DISPLAY_PROPERTIES. Тем не менее, в результирующем массиве присутствует массив PROPERTIES со всеми-всеми свойствами... Зачем создавать лишние выборки?!
- Ну и косвенный момент - новые дефолтные шаблоны каталога наворочены страшно, написаны совершенно нечитабельным кодом. Кастомизировать их - это значит стереть весь код и написать с нуля. Надо как-то по-нормальному сделать дефолтные шаблоны, чтобы их можно было понять кому-либо, кроме их создателя...
Евгений, с целью сохранения совместимости можно просто создать новый набор компонентов, а этот каталог и новости плавно уйдут в прошлое
Пока такой необходимости не видим.
P.S. Кстати, Антон, Вы совершенно неверно трактуете содержимое ключа DISPLAY_PROPERTIES. Туда попадают НЕПУСТЫЕ свойства из числа тех, что указаны к выводу. И, например, организация табличного вывода свойств без дополнительных затрат возможна только при реализованном подходе.
P.S. Кстати, Антон, Вы совершенно неверно трактуете содержимое ключа DISPLAY_PROPERTIES. Туда попадают НЕПУСТЫЕ свойства из числа тех, что указаны к выводу. И, например, организация табличного вывода свойств без дополнительных затрат возможна только при реализованном подходе.
Евгений, это понятно, но мы в этом случае приходим к проблеме нагрузок на крупных интернет-магазинах с множеством технических характеристик товаров (по которым должна быть фильтрация). Ладно бы еще эти все свойства выбирались только в детальной карточке товара, так они и в списках тоже выбираются! А если свойств 500, 1000? Битрикс - это же мега-производительная система (как заявлено), подходящая для крупных интернет-магазинов ))))))
По поводу названий "Новости" и "Каталог" - чисто концептуально, у нас офисы - новости, партнеры - новости... Не по-феншую просто 
| Евгений, это понятно, но мы в этом случае приходим к проблеме нагрузок на крупных интернет-магазинах с множеством технических характеристик товаров (по которым должна быть фильтрация). Ладно бы еще эти все свойства выбирались только в детальной карточке товара, так они и в списках тоже выбираются! А если свойств 500, 1000? Битрикс - это же мега-производительная система (как заявлено), подходящая для крупных интернет-магазинов )))))) |
нет там больше огромного количества запросов. 500, 1000 свойств - все равно 3 запроса
)))))))))))))))))))))))))))))))))))))) 3 тысячаэтажных запроса лефт-джойнов? )))))
mysql имеет ограничение на 30 join в запросе.
Если это так - тогда это будет просто супер!
© 2001-2022 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
п.2 - не можем из-за сохранения совместимости
п.3 - работаем над этим, ждите ближайших обновлений.