Продолжаем тему компонент 2.0. На сей раз опишу потенциальную проблему, с которой можно столкнуться при написании своих компонент. В качестве примера берем типовой bitrix:news.list. [spoiler] Создаем инфоблок с несколькими свойствами, у которых не указываем символьный код (не обязаны): Кидаем на страницу компонент bitrix:news.list и начинаем настраивать. Выбираем инфоблок, переходим к выбору свойств, которые надо показывать. Упс: Для выбора доступно только последнее Лезем в настройки инфоблока, прописываем символьные коды для пары свойств, одно оставляем пустым (бедна фантазия на символьные коды под вечер ): Смотрим настройки компонента - отлично, все свойства есть: Все окей, настроили компонент, смотрим публичку (пардон, набивать элементы было лень, придется поверить ). Все выводится, вот только свойство с пустым символьным кодом не показывается, хоть ты тресни. Вместо того, чтобы истерить на форуме и мотать нервы саппорту, лезем в код и начинаем разбираться.
Как получается перечень значений для параметра "Свойства" (PROPERTY_CODE) (.parameters.php компонента):
Нас интересует массив $arProperty_LNS. Ключами массива как раз и являются символьные коды свойств инфоблока. Натурально, если у нескольких свойств код пустой, остаться должен только один - последний Это ответ на первую пару скриншотов. Вторая пара скринов требует залезть уже в component.php:
if(!is_array($arParams["PROPERTY_CODE"]))
$arParams["PROPERTY_CODE"] = array();
foreach($arParams["PROPERTY_CODE"] as $key=>$val)
if($val==="")
unset($arParams["PROPERTY_CODE"][$key]);
В переводе на русский - пустые ключи выбрасываются. Причем самое грустное то, что в методе _CIBElement::GetProperties() проблема пустых символьных кодов решена - если их нет, ставятся ID свойств.
Вывод - в своих компонентах в качестве ключей лучше использовать ID свойств:
if (false == is_array($arParams['PROPERTY_CODE']))
$arParams['PROPERTY_CODE'] = array($arParams['PROPERTY_CODE']);
foreach ($arParams['PROPERTY_CODE'] as $key => $value)
{
if (0 >= intval($value))
unset($arParams['PROPERTY_CODE'][$key]);
}
Преимущества - избавлены от проблем, описанных выше, легкость валидации в component.php Недостатки - неудобно переносить страницы с тестовой машины на боевую, если, к примеру, не совпадают ID инфоблоков.
Символьный код для того и придуман, что он не должен меняться. И админ должен это понимать и следить за этим. В случае же с числовыми ID вы вообще не можете их изменить (кроме прямых правок в базе). И если свойство было удалено, а потом снова добавлено, ему никак не вернуть прежний числовой ID, а вот символьный код - запросто.
В принципе, я понимаю, почему вам так нравится использовать ID. В компонентах, подобных news.list, где все свойства выводятся в кучу и выглядят одинаково, это оправдано. Однако мне чаще попадались задачи, когда нужно каким-либо образом выделять конкретные свойства и делать с ними что-то специфическое. Отобразить свойства в нужном порядке и в нужных местах HTML-верстки. Добавить какие-либо проверки или фильтры. Обычно это делается в шаблоне компонента и нужно для конкретного проекта. Поэтому мне больше по душе символьные коды
Не должен - это еще не значит, что не будет. Тут мы с Вами практически поменялись местами. Мне нравится использовать ID по 2 причинам: 1. Гарантированная уникальность в пределах всего проекта (ради эксперимента можно попробовать навтыкать один и тот же символьный код у всех свойств одного инфоблока) 2. Легкость проверки в $arParams - простейший intval
Что касается задач, то у меня даже новости в проектах часто требуют специфической обработки свойств. Хотя, согласен, при модификации шаблонов стандартных компонент для разработчика удобнее, т.е. ленивее.
Я таки за поле CODE, поскольку оно человекочитаемо и можно понять что происходит.
Мы вообще на продакшене ничего не настраиваем, а выгружаем нужный релиз из SVN. Поэтому даже если поменяли структуру БД, то по полю CODE гораздо проще найти хвосты. Имхо.
М... ну смотрите, есть проект. На проекте есть ведущий разработчик. Именно он отвечает за структуру данных и ER-ку. Только он и правит существующие ИБ и прочее. Т.е. если нужно программеру добавить чего, то или с санкции и ведома ведущего добавляет или ведущий сам. Естественно обновляется и ER-ка. Потом апдейт хранилища с документацией и при желании её все кто нужно печатают повторно.
Так даже когда в команде больше 2 человек, то контроль не теряется и не появляются загадочные свойства, которые незнамо кто насоздавал и чёрт его знает где использует.
Сейчас не припомню, но вроде при сквозной выборке свойств из нескольких ИБ по символьному коду битрикс валится в ошибку MySQL если одного из свойств в одном из ИБ недостаёт.
Что-то такое писал народ в теме по новому функционалу CIBlockElement::GetList(), помню. Но мне такая выборка, к счастью, только в страшном сне может присниться
Несомненно. Но, Макс, Вы форум последние три месяца читаете? Который гостевой, в основном? Критическая масса лемингов, от которых все можно ожидать, там уже перейдена. Так что...
Хотя, конечно, согласен, попытка решить техническими способами административные проблемы обречена на провал
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».