Продолжаем тему компонент 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 инфоблоков.
Предположим, вы хотите одно из свойств отобразить на детальной странице особым образом образом (скажем, другим шрифтом). Или же вы хотите добавить фильтр по какому-либо свойству (допустим, отобразить только те элементы, у которых свойство FILE заполнено). Что предпочтительно использовать в таких случаях, ID или CODE? Если будете использовать ID, будут возникать проблемы с переносом кода с тестовой машины. Да и вообще, удаляем свойство в инфоблоке и создаем заново - и уже ничего не работает. Или пересоздаем инфоблок, реакция та же.
Тезка, Вы мой пост читали? Последнее предложение в нем - это ужатая версия Вашего комментария вообще-то
Приведу еще один аргумент в пользу ID, особенно если пишем компоненты на заказ (универсальные). Количество народа, собирающего сайты на готовых шаблонах/компонентах, ни черта при этом в Битриксе не понимающего, поражает. И вот тут-то проблема может вылезти.
И уж не вижу большого труда не копировать папки с локали, а заново настроить компонент. Я, кстати, не копирую.
Тезка, Вы мой пост читали? Последнее предложение в нем - это ужатая версия Вашего комментария вообще-то
Я заострил на этом внимание, потому что оно перечеркивает весь предыдущий текст поста.
Приведу еще один аргумент в пользу ID, особенно если пишем компоненты на заказ (универсальные). Количество народа, собирающего сайты на готовых шаблонах/компонентах, ни черта при этом в Битриксе не понимающего, поражает. И вот тут-то проблема может вылезти.
Где ж вы тут видите универсальность, если вместо символьных кодов в компоненте прописаны ничего не значащие часто изменяющиеся айдишники? Это называется хардкод, а не универсальность. А для того, чтобы не понимающий народ не обжигался, лучше бы в админке запретили не указывать символьные коды (это уже камень в огород разработчиков Битрикс).
И уж не вижу большого труда не копировать папки с локали, а заново настроить компонент. Я, кстати, не копирую.
А если компонент не один, а их на разных страницах сайта десятки? И синхронизировать локальную версию сайта с рабочей нужно не один раз, а много?
Я заострил на этом внимание, потому что оно перечеркивает весь предыдущий текст поста.
Я понимаю Вашу позицию. Позволю себе назвать ее "разработчику лень напрягаться", уж простите за грубость. В ответ могу привести огромное количество вариантов, когда привязка к символьным кодам только добавит проблем. Самый простой - настроили Вы свои десятки страниц, а потом пришел другой админ и поменял символьный код одного из свойств. Что делать будем?
это уже камень в огород разработчиков Битрикс
Вы уж простите за нескромный вопрос - Вам что-нибудь словосочетание "один ко многим" говорит? Это насчет "ничего не значащие часто изменяющиеся айдишники". Они вообще-то заводятся один раз (я про таблицу свойств). Универсальность же в моей фразе относилась к компонентам, которые делаются не ради одного проекта, а ради серии без модификаций.
если компонент не один, а их на разных страницах сайта десятки? И синхронизировать локальную версию сайта с рабочей нужно не один раз, а много?
Я не сторонник мазохизма. Если такая ситуация реальна, значит, пора менять идеологию разработки.
Символьный код для того и придуман, что он не должен меняться. И админ должен это понимать и следить за этим. В случае же с числовыми ID вы вообще не можете их изменить (кроме прямых правок в базе). И если свойство было удалено, а потом снова добавлено, ему никак не вернуть прежний числовой ID, а вот символьный код - запросто.
В принципе, я понимаю, почему вам так нравится использовать ID. В компонентах, подобных news.list, где все свойства выводятся в кучу и выглядят одинаково, это оправдано. Однако мне чаще попадались задачи, когда нужно каким-либо образом выделять конкретные свойства и делать с ними что-то специфическое. Отобразить свойства в нужном порядке и в нужных местах HTML-верстки. Добавить какие-либо проверки или фильтры. Обычно это делается в шаблоне компонента и нужно для конкретного проекта. Поэтому мне больше по душе символьные коды
Не должен - это еще не значит, что не будет. Тут мы с Вами практически поменялись местами. Мне нравится использовать ID по 2 причинам: 1. Гарантированная уникальность в пределах всего проекта (ради эксперимента можно попробовать навтыкать один и тот же символьный код у всех свойств одного инфоблока) 2. Легкость проверки в $arParams - простейший intval
Что касается задач, то у меня даже новости в проектах часто требуют специфической обработки свойств. Хотя, согласен, при модификации шаблонов стандартных компонент для разработчика удобнее, т.е. ленивее.
Я таки за поле CODE, поскольку оно человекочитаемо и можно понять что происходит.
Мы вообще на продакшене ничего не настраиваем, а выгружаем нужный релиз из SVN. Поэтому даже если поменяли структуру БД, то по полю CODE гораздо проще найти хвосты. Имхо.
М... ну смотрите, есть проект. На проекте есть ведущий разработчик. Именно он отвечает за структуру данных и ER-ку. Только он и правит существующие ИБ и прочее. Т.е. если нужно программеру добавить чего, то или с санкции и ведома ведущего добавляет или ведущий сам. Естественно обновляется и ER-ка. Потом апдейт хранилища с документацией и при желании её все кто нужно печатают повторно.
Так даже когда в команде больше 2 человек, то контроль не теряется и не появляются загадочные свойства, которые незнамо кто насоздавал и чёрт его знает где использует.
Сейчас не припомню, но вроде при сквозной выборке свойств из нескольких ИБ по символьному коду битрикс валится в ошибку MySQL если одного из свойств в одном из ИБ недостаёт.
Что-то такое писал народ в теме по новому функционалу CIBlockElement::GetList(), помню. Но мне такая выборка, к счастью, только в страшном сне может присниться
Несомненно. Но, Макс, Вы форум последние три месяца читаете? Который гостевой, в основном? Критическая масса лемингов, от которых все можно ожидать, там уже перейдена. Так что...
Хотя, конечно, согласен, попытка решить техническими способами административные проблемы обречена на провал
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».