Раньше, для того, чтобы создать какое-либо структурированное свойство, нам приходилось реализовывать ряд «костылей». Например, как представить свойство Адрес, которое состоит из города, улицы, номера дома, квартиры, индекса… Ладно, если оно одиночное, можно было бы просто настроить форму редактирования элемента.
А если свойство множественное, т. е. если объект имеет несколько адресов?
Раньше приходилось при помощи JavaScript на лету разбивать такое свойство на несколько полей, а уже при изменении полей, заносить всё в скрытое поле в формате JSON, и при последующем редактировании элемента распарсивать эту строку в несколько полей.
Либо же нужно было создавать новый тип свойства под свои нужды.
Так же были варианты реализовать такой костыль при помощи целого инфоблока, что очень ресурсозатратно.
Решение проблемы:
[spoiler]
1. Визуальное представление
Забудем о костылях, теперь всё неимоверно просто:
a. Забиваем информацию о свойстве и выбираем тип «Набор свойств»
· Строка
· Число
· Привязка к разделам
· Привязка к элементам
· Дата/время
· Привязка к файлу (на сервере)
· Счётчик
· Привязка к элементам с автозаполнением
· Привязка к товарам (SKU)
· Привязка к карте Google Maps (test)
· Привязка к карте Yandex (test)
· Привязка к пользователю
· Привязка к теме форума
Каждое подсвойство также имеет свои настройки, например рассмотрим настройки подсвойства «привязка к элементам в виде списка»
Удобно, не правда ли? В списке элементов, это выглядит следующим образом:
Всё до безобразия просто: возьмём к примеру компонент «список новостей», в массиве $arItem[“PROPERTIES”]($arItem – элемент массива $arResult[“ITEMS”]) будет наше свойство ADDRESS и будет иметь следующую структуру
$arItem[“PROPERTIES”][“ADDRESS”][“VALUE”][0][“CITY”] - город |
$arItem[“PROPERTIES”][“ADDRESS”][“VALUE”][0][“ F_ADDRESS”] – фактический адрес |
И так далее. Т.е в VALUE[0] ключами являются символьные коды подсвойств.
При выборе такого свойства в GetList: PROPERTY_ADDRESS_VALUE будет иметь такую же структуру, т.е:
$arItem[“PROPERTY_ADDRESS_VALUE”][0][“CITY”] – город $arItem[“PROPERTY_ADDRESS_VALUE”][0][“ F_ADDRESS”] – фактический адрес |
3. Как фильтровать по свойству «Набор свойств»
К сожалению здесь не всё так хорошо, в битриксе нет обработчика на формирование фильтра к свойству, поэтому приходится немножко "костылять":
Например, фильтрация по подсвойству Город:
$arFilter[“?PROPERTY_ADDRESS”]=”CITY && 1234”, где CITY – символьный код подсвойства, 1234 – значение подсвойства, в данном случае ID города.
4. Как добавлять/обновлять свойство:
Тут тоже есть небольшая особенность… в общем, выглядит это так:
$arAddres = array(
"F_ADDRESS"=>$props["F_ADDRESS"]["VALUE"],
"L_ADDRESS"=>$props["U_ADDRESS"]["VALUE"],
"CITY"=>$arCities[$props["CITY"]["VALUE_ENUM_ID"]],
"GEO_POSITION"=>$props["GEO_POS"]["VALUE"],
);
CIBlockElement::SetPropertyValuesex($ELEMENT_ID,false, array("ADDRESS" =>serialize($arAddres))); |
В общем то всё. Ждём вашей критики и предложений.
PS: Решение доступно в MARKETPLACE 1C – Битрикс.
$arFilter[“?PROPERTY_ADDRESS”]=”CITY && 1234”, где CITY – символьный код подсвойства, 1234 – значение подсвойства, в данном случае ID города.
А привязка к файлу на сервер глючно работает!
Важные моменты:
1. При проверке обязательности групп свойств выдает ошибку что не заполнены поля. Например: 1 свойство в группе - список из инфоблоков, 2 - число. При галочке обязательности заполнения не проходит проверку на заполнение.
2. При выводе свойств из компонента выдает id значения, если это список из элементов другого инфоблока.
Например: 104 / 1231. 104 - id элемента (а должно быть название элемента), 1234 - число.
3. При штатной выгрузке нет понимания о группе свойств (пишет Array ())
4. При изменении дополнительных свойств свойства в наборе не сохраняет (и не выводит) их свойства, такие как:
Скажите, можно ли поправить данные ошибки. Заранее благодарю.
А как можно сортировать по подсвойству времени, причём ">"/"<"?
У меня 4 поля внутри. Выдает array..
Жаль что не поддерживате, идея - супер!