Идеи пользователя 32566
При обновлении и добавлении элементов инфоблоков нужно убрать дополнительные обработки передаваемых значений свойств типа файл (PROPERTY_TYPE=F), если эти свойства являются кастомными (USER_TYPE != "" ).
Например, в файле /bitrix/modules/iblock/admin/iblock_element_edit.php (строка ~568 ) нужно убрать преобразование значения через функцию CIBlock::makeFilePropArray(...).
Это позволит создавать свои загрузчики файлов, которые будут иметь предсказуемую разработчиком логику. Сейчас же с выпуском обновления Битрикса мой модуль перестал работать из-за того, что передаваемый в значение ID файла:
с какого-то фига вдруг превратился в:
Если свойство кастомное то на вход функции ConvertToDB должно поступать ровно то, что отправлено через форму редактирования или через какие-либо средства API.
P.S. В данный момент пришлось переключить свой модуль с использования типа "F" на "N", что накладывает ограничение на использование кастомного свойства в штатных шаблонах решений от Битрикса.
Например, в файле /bitrix/modules/iblock/admin/iblock_element_edit.php (строка ~568 ) нужно убрать преобразование значения через функцию CIBlock::makeFilePropArray(...).
Это позволит создавать свои загрузчики файлов, которые будут иметь предсказуемую разработчиком логику. Сейчас же с выпуском обновления Битрикса мой модуль перестал работать из-за того, что передаваемый в значение ID файла:
array("VALUE"=>777); |
[VALUE] => Array( [name] => [type] => [tmp_name] => [error] => 4 [size] => 0 ) |
P.S. В данный момент пришлось переключить свой модуль с использования типа "F" на "N", что накладывает ограничение на использование кастомного свойства в штатных шаблонах решений от Битрикса.
Чтобы наступил для разработчиков рай нужно:
- User-friendly.
Дать возможность в методах
CIBlockParameters::GetInheritedPropertyTemplateSectionMenuItems()
CIBlockParameters::GetInheritedPropertyTemplateElementMenuItems()
добавлять свои шаблоны подстановки через обработчики событий. Чтобы сеошникам было удобно подставлять шаблоны через вот это меню
- Developer-friendly.
Добавить {=this.ID}, {=parent.ID}, {=iblock.ID} для использования в пользовательских функциях. Почему сразу это не было сделано - непонятно.
При разработке собственных свойств инфоблока создается метод ConvertFromDB, назначение которого - преобразовывать значения свойства в требуемый разработчику вид.
Создавая сложные свойства разработчики иногда используют дополнительное поле описания значения свойства - "DESCRIPTION", куда сохраняют сопутствующие значению данные в сериализованном виде.
То есть фактически получается, что значение свойства состоит из кортежа {VALUE,DESCRIPTION}.
Проблема в том, что при выборках CIBlockElement::GetList в метод свойства ConvertFromDB не поступает значение поля "DESCRIPTION" (передается почему-то пустая строка). Что не позволяет правильно сформировать полноценное значение свойства.
Проблема находится в файле: /bitrix/modules/iblock/classes/general/iblockresult.php (строка 196).
Нужно заменить вот это:
На примерно вот это:
То есть передаем в метод ConvertFromDB сопутствующее значению описание DESCRIPTION.
Для чего это всё.
Пример сложного свойства: вставки в ювелирные украшения. Значение представляет собой кортеж {типКамня,каратность,количество}. Тип камня (ID) хранится в поле VALUE, каратность и количество - в DESCRIPTION в сериализованном виде. Данная структура позволяет делать выборки элементов инфоблока по типу камня.
При текущем положении вещей постоянно приходится преобразовывать значения в нужный вид в result_modifier.php.
А если свойство входит в состав какого-то решения из маркетплейса, то разработчик, который использует это решение может только догадываться как преобразовать значения свойства в нормальный вид.
Создан тикет в техподдержку: 512438
Создавая сложные свойства разработчики иногда используют дополнительное поле описания значения свойства - "DESCRIPTION", куда сохраняют сопутствующие значению данные в сериализованном виде.
То есть фактически получается, что значение свойства состоит из кортежа {VALUE,DESCRIPTION}.
Проблема в том, что при выборках CIBlockElement::GetList в метод свойства ConvertFromDB не поступает значение поля "DESCRIPTION" (передается почему-то пустая строка). Что не позволяет правильно сформировать полноценное значение свойства.
Проблема находится в файле: /bitrix/modules/iblock/classes/general/iblockresult.php (строка 196).
Нужно заменить вот это:
if(is_array($this->arIBlockConvProps))
{
foreach($this->arIBlockConvProps as $strFieldName=>$arCallback)
{
if(is_array($res[$strFieldName]))
{
foreach($res[$strFieldName] as $key=>$value)
{
$arValue = call_user_func_array($arCallback["ConvertFromDB"], array($arCallback["PROPERTY"], array("VALUE"=>$value,"DESCRIPTION"=>"")));
$res[$strFieldName][$key] = $arValue["VALUE"];
}
}
else
{
$arValue = call_user_func_array($arCallback["ConvertFromDB"], array($arCallback["PROPERTY"], array("VALUE"=>$res[$strFieldName],"DESCRIPTION"=>"")));
$res[$strFieldName] = $arValue["VALUE"];
}
}
}
|
if(is_array($this->arIBlockConvProps))
{
foreach($this->arIBlockConvProps as $strFieldName=>$arCallback)
{
$propID = $arCallback["PROPERTY"]["ID"];
$propCode = $arCallback["PROPERTY"]["CODE"];
$desc = $res["DESCRIPTION_".$propID];
if(empty($desc)) $desc = $res["PROPERTY_".$propID."_DESCRIPTION"];
if(empty($desc)) $desc = $res["PROPERTY_".$propCode."_DESCRIPTION"];
if(is_array($res[$strFieldName]))
{
foreach($res[$strFieldName] as $key=>$value)
{
$arValue = call_user_func_array($arCallback["ConvertFromDB"], array($arCallback["PROPERTY"], array("VALUE"=>$value,"DESCRIPTION"=>$desc[$key])));
$res[$strFieldName][$key] = $arValue["VALUE"];
}
}
else
{
$arValue = call_user_func_array($arCallback["ConvertFromDB"], array($arCallback["PROPERTY"], array("VALUE"=>$res[$strFieldName],"DESCRIPTION"=>$desc)));
$res[$strFieldName] = $arValue["VALUE"];
}
}
}
|
Для чего это всё.
Пример сложного свойства: вставки в ювелирные украшения. Значение представляет собой кортеж {типКамня,каратность,количество}. Тип камня (ID) хранится в поле VALUE, каратность и количество - в DESCRIPTION в сериализованном виде. Данная структура позволяет делать выборки элементов инфоблока по типу камня.
При текущем положении вещей постоянно приходится преобразовывать значения в нужный вид в result_modifier.php.
А если свойство входит в состав какого-то решения из маркетплейса, то разработчик, который использует это решение может только догадываться как преобразовать значения свойства в нормальный вид.
Создан тикет в техподдержку: 512438
При создании нового типа почтового события почему бы не сделать кнопку добавления шаблона для этого события во вкладке "Шаблоны"?
Даже простая ссылка на страницу создания шаблона ускорит работу.
Даже простая ссылка на страницу создания шаблона ускорит работу.
Сделайте, наконец, штатный функционал некешируемых областей в шаблонах компонентов.
Сейчас у вас есть функции CMain:: ShowViewContent и CMain::AddViewContent. Но они работают только в направлении (как я понял) шаблон компонента -> шаблон сайта.
Хотелось бы, чтобы оно работало в рамках шаблона компонента.
То есть, например, в template.php вставляли ShowUncachedContent("uncache");
А в component_epilog.php (или в любой другой некешируемой части сайта) задавали контент этой некешируемой области через SetUncachedContent("uncache");
Типичная задача: показывать на странице товара в интернет-магазине "Купить" или "Уже в корзине" в зависимости от статуса товара.
Сейчас у вас есть функции CMain:: ShowViewContent и CMain::AddViewContent. Но они работают только в направлении (как я понял) шаблон компонента -> шаблон сайта.
Хотелось бы, чтобы оно работало в рамках шаблона компонента.
То есть, например, в template.php вставляли ShowUncachedContent("uncache");
А в component_epilog.php (или в любой другой некешируемой части сайта) задавали контент этой некешируемой области через SetUncachedContent("uncache");
Типичная задача: показывать на странице товара в интернет-магазине "Купить" или "Уже в корзине" в зависимости от статуса товара.
Добавить возможность помечать задачи как избранные и выводить их в специальном блоке чтобы были всегда на виду.
Сейчас при нахождении на странице двух и более форм добавления элементов инфоблока форма, которая находится выше по коду перехватывает данные из формы, которая ниже.Как пример: в шапке форма заказа звонка, на странице форма заявки чего-либо.
Это происходит из-за того, что идет проверка на наличие в отправленных данных ключа "iblock_submit" (или "iblock_apply"). У всех форм этот ключ одинаков.
В компоненте нужно сделать примерно вот так:
Тогда данные, переданные из одной формы, не будут попадать в обработку другой форме.
Это касается также и формы регистрации (да, бывает такое, что нужно две формы регистрации на странице - юрики и физики).
Это происходит из-за того, что идет проверка на наличие в отправленных данных ключа "iblock_submit" (или "iblock_apply"). У всех форм этот ключ одинаков.
if (check_bitrix_sessid() && (!empty($_REQUEST["iblock_submit"])
|| !empty($_REQUEST["iblock_apply"]))){...}
|
В компоненте нужно сделать примерно вот так:
$FORM_ID = $arParams["FORM_ID"];
if (check_bitrix_sessid() && (!empty($_REQUEST["iblock_submit_".$FORM_ID])
|| !empty($_REQUEST["iblock_apply_".$FORM_ID]))){...} |
Это касается также и формы регистрации (да, бывает такое, что нужно две формы регистрации на странице - юрики и физики).
- 30.05.2012 17:15: Блин, и вебформы тоже такие же кривые. Это совсем не серьезно
- 30.05.2012 18:19: Мда, несколько веб-форм на одной странице работают, но оказывается нельзя выводить однотипные веб формы в цикле при их работе по AJAX! Все из-за того, как подсказал коллега, что идендификатор сессии ajax-запроса формируется по номеру строки скрипта o_0 Хорошо, что веб-форм всего 9 (кол-во услуг)...
Сейчас это реализовано только на странице редактирования/добавления элемента.
Дать возможность для компонента включаемой области изменять заголовок, который выводится в режиме редактирования в контекстном меню компонента.
Сейчас для всех областей заголовки одинаковы "Изменить область".
Иногда приходится несколько включаемых областей размещать на страницы комплексного компонента и тогда это превращается вот в такую неприятность:
Было бы более "юзерфрендли" делать заголовки типа "Изменить логотип", "Редактировать блок контактов", "Изменить телефон" и т.д.
Можно дополнительным параметром в компонент передавать этот заголовок.
ПС. Ну и для "Добавить область" такая же история.
Сейчас для всех областей заголовки одинаковы "Изменить область".
Иногда приходится несколько включаемых областей размещать на страницы комплексного компонента и тогда это превращается вот в такую неприятность:
Было бы более "юзерфрендли" делать заголовки типа "Изменить логотип", "Редактировать блок контактов", "Изменить телефон" и т.д.
Можно дополнительным параметром в компонент передавать этот заголовок.
ПС. Ну и для "Добавить область" такая же история.
Если значения свойств хранятся в отдельной таблице, то выборка:
сработает неправильно. Выберутся только товары из одного инфоблока.
Это нужно для вывода, например, новинок каталога, когда каталог товаров в крупном магазине реализован через множество инфоблоков, и каждый инфоблок является разделом каталога.
Приходится перебирать все инфоблоки в цикле, что не совсем гут.
$res = CIBlockElement::GetList(array("sort"=>"asc"),array("IBLOCK_TYPE"=>"catalog","PROPERTY_BESTSELLER"=>"Y"));
|
Это нужно для вывода, например, новинок каталога, когда каталог товаров в крупном магазине реализован через множество инфоблоков, и каждый инфоблок является разделом каталога.
Приходится перебирать все инфоблоки в цикле, что не совсем гут.
Ответил 
Жуков Евгений 03.02.2012 16:46:38
Жуков Евгений 03.02.2012 16:46:38
Это единственный выход для такой ситуации.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
