Насколько я понял, начиная с 4 версии, в Битриксе по умолчанию корневым элементом каталога является "Информационный блок", и все его подблоки (группы) имею т тот же набор свойств, что и родительский. А мне необходимо разделить инфоблоки по разделам,например: Техника для дома ->Холодильники --->Alasha --->Birusa ->Телевизоры --->Bosh Техника для офиса ->Принтеры --->Epson ->Компьютеры --->LG --->IBM , причем в холодильниках, телевизорах, принтерах итд определены различные свойства, и эти свойства наследуются ниже по дереву, главные группы товаров имеют только название.
Единственный способ, который я нашел - это создание общего инфоблока "Товары", у которых есть название и параметр типа ID, и привязка этого инфоблока к инфоблокам типов товаров.
Гость пишет: Насколько я понял, начиная с 4 версии, в Битриксе по умолчанию корневым элементом каталога является "Информационный блок", и все его подблоки (группы) имею т тот же набор свойств, что и родительский.
Структура модуля инфоблоков принципиально не менялась при переходе между версиями 3.хх и 4.хх.
"Тип инфоблоков", дадее непосредственно "информационный блок" и уже в нем элементы с определенными свойствами, которые могут быть каталогизированы по любому количеству групп.
Свойства элементов определяются конкретного информационного блока и не меняются в зависимости от групп. Такую модель мы выбрали по соображениям производительности и особенностям MySQL. В одном из наших продуктов, "Битрикс: Инфо-портал" мы делали наследование свойств по группам, но клиенты не пользовались такой возможностью и реально даже на MSSQL с подзапросами это существенно затрудняло работу систем с большими каталогами.
Для создания более сложных каталогизаций с использованием "Битрикс: Управление сайтом" используются следующие свойства инфо-блоков: "Привязка к разделам" и "Привязка к элементам". Эти свойства позволяют устанавливать связи с другими инфо-блоками и использовать их для создания по сути любых систем каталогов.
Вспомогательная ссылка для документации разработчика по модулю инфо-блоков:
Гость пишет: А мне необходимо разделить инфоблоки по разделам,например: Техника для дома ->Холодильники --->Alasha --->Birusa ->Телевизоры --->Bosh Техника для офиса ->Принтеры --->Epson ->Компьютеры --->LG --->IBM , причем в холодильниках, телевизорах, принтерах итд определены различные свойства, и эти свойства наследуются ниже по дереву, главные группы товаров имеют только название.
Учитывая, что свойства можно назначать на инфо-блоки, я бы посоветовал вам создать отдельные инфо-блоки для телевизоров, холодильников, компьютеров и наполнить их нужными для представления свойствами. Общий каталог представить в виде отдельного инфо-блока Товаров. И во всех каталогах где будут храниться товары, сделать свойство "привязка к элементам" указывающее на каталог Товаров.
Можно так же производителей выделить в отдельный инфо-блок, чтобы проводить связи между разными моделями техники в случае, когда они выпущены одним производителем.
Цитата
Гость пишет: Единственный способ, который я нашел - это создание общего инфоблока "Товары", у которых есть название и параметр типа ID, и привязка этого инфоблока к инфоблокам типов товаров.
Если я правильно понял, предложенный мной метод совпадает с выбранным вами.
Цитата
Гость пишет: Техподдержка у них рулит... Два дня уже не могут ответить... Тут гляжу тоже... За штуку баксов могли бы ответить на пару протых вопросов..
Техническая поддержка в первую очередь обрабатывает запросы, поступающие от коммерческих клиентов в виде тикетов в разделе поддержки http://www.bitrixsoft.ru/support/ Потом обрабатываются закрытые форум, к которым есть доступ у всех коммерческих клиентов и партнеров.
И, к сожалению, в последнюю очередь мы стараемся отвечать на вопросы в открытом форуме.
На прошлой неделе мы выпустили обновление модуля поиска, которое включило морфологию для русского и английского языка и это вызвало много вопросов от клиентов и обсуждение в закрытом форуме.
А почему нельзя создать тип инфоблока "Техника для дома" и там создавать инфоблоки "Холодильники", "Телевизоры" и тыды. А потом создать тип инфоблока "Техника для офиса" и там создавть свои инфоблоки?
Ответ дан в рамках техподдержки. Хочу обратить Ваше внимание, что вопрос был задан 13 августа, в субботу, а суббота и воскресенье являются выходными днями, в том числе и для службы технической поддержки.
Если у Вас возникнут дополнительные вопросы, задайте их, пожалуйста в рамках того же ображения в техподдержке, это ускорит ответ и сделает диалог более удобным.
Сорри, погорячился - у меня обычно нет дней недели, думал, поддержка онлайн, да и тут срочно надо было... Доку я читал, хорошая, только с назначением сущностей долго разбирался - может, отдохнуть надо? Я вообще ее первый раз вижу Кстати, система на пятерке смотреться будет (с программного уровня). А с наследуемыми свойствами - обычная дилема гибкость механизма / сложность использования, тут понимаю, что отказались, хотя можно было предложить альтернативный механизм (Alter-ить таблицы, вы же инкапсулируете интерфейс БД) - он и побыстрее Мне не нужны были наследуемые свойства, нужно было разделить Типы товаров (с возможным разбиением на группы) на супергруппы, так сказать, т.е весь каталог: Boots - класс товаров с внутренней организацией по каталогам; Cars - класс товаров с внутренней организацией по каталогам; Catalog - весь каталог, содержит Boots и Cars. В общем, сделал уже... Всем спасибо. PS: Кстати, Анатолий предложел неплохое решение, поздно правда, но все равно спасибо, до меня не дошло.
Гость пишет: А с наследуемыми свойствами - обычная дилема гибкость механизма / сложность использования, тут понимаю, что отказались, хотя можно было предложить альтернативный механизм (Alter-ить таблицы, вы же инкапсулируете интерфейс БД) - он и побыстрее
О, это совсем нежизнеспособный метод. Просчитывали, но базы не выдерживают, фрагментации, перестроения, удаления часто невозможны... в общем, не проходит Alter к таблицах, хоть и понятно, что это будет быстрее.
Сергей. А вот у меня такая проблемка. (Я Вам тут задам, если можно). Вот уже есть два, а то и три проекта, в которых очень бы пригодились дополнительные свойства у разделов. Ведь это не так сложно сделать то в общем то. Почему этого нет и не планируется ли в ближайшем будущем?
Анатолий Зайченок пишет: от уже есть два, а то и три проекта, в которых очень бы пригодились дополнительные свойства у разделов. Ведь это не так сложно сделать то в общем то. Почему этого нет и не планируется ли в ближайшем будущем?
Сергей, на базе данных без подзапросов, а таковой являются версии MySQL 3.ХХ и 4.ХХ которые в основном сейчас используются, создание наследуемых свойств по разделам задача далеко не простая. Сразу возникают проблемы переноса объекта из папки в папку (что должно со свойствами случиться, если их в другой папке нет?) множественной связи объекта с несколькими папками и ряд других проблем. Ну и производительность такой системы будет заметно ниже.
Как я уже говорил, мы создавали такие продукты, но потребителя они не нашли в силу сложности интерфейсов и ряда технических ограничений.