Цитата |
---|
Николай Рыжонин пишет: Думаю выборка вида, но по второму типу инфоблоков должна как по скорости устроить так и по функционалу. |
09.03.2011 22:51:55
В общем, не знаю конкретно какую задачу вы решаете этой выборкой, но в целом ситуация такая: при работе через _CIBElement у вас на каждый элемент будет формироваться плюс один запрос на выборку свойств (это помимо базовых для всей выборки). А если работать через CIBlockResult, то основная выборка увеличится на количество запросов, равное выбираемым свойствам и для каждого такого свойства будет добавлено по "джойну" в основную выборку, т.е. здесь появляется ограничение на количество выбираемых одновременно свойств. Также в последнем варианте появляются еще некоторые неудобства с работой по множественным свойствам - они формируются как отдельный элемент. Пример выборки через _CIBElement:
Пример выборки через CIBlockResult:
Т.е. для _CIBElement указываем PROPERTY_* в $arSelect, а для CIBlockResult перечисляем нужные свойства. _CIBElement - теоретически не имеет ограничений по количеству свойств, но очень тяжел при выборке большого количества элементов с большим количеством свойств. Подходит для универсальных компонентов вывода списков элементов с постраничной навигацией. CIBlockResult - наиболее экономичен, но на практике пригоден только для "ручных" выборок, когда заранее известно количество свойств и их меньше 30, например. Какое точно ограничение не могу сказать, т.к. помимо джойнов для свойств выполняются и джойны для других сущностей. Максимум же в MySQL 61 джойн, если не ошибаюсь. И не следует забывать про особенность возвращаемого результата с множественными значениями свойств. Какой способ наиболее выгоден вам, думаю, определите сами. |
|||||||||
|
09.03.2011 20:39:04
Если не важен контроль при многосайтовости и нет никаких особенностей с распределением прав (все пользователи могут читать), то лучше так:
Но главный здесь тормоз $arSelect, попробуйте так:
и саму выборку как описал постом выше, лишние/нужные свойства отбирайте уже в самой выборке простыми условными операторами. |
|||||||
|
09.03.2011 19:45:01
Но вообще свойства обычно лучше выбирать так:
$arSelect = array( ..., PROPERTY_* ); $rsElements = CIBlockElement::GetList($arSort, $arFilter, $arGroup, $arNavParams, $arSelect); while($obElement = $rsElements->GetNextElement()) { $arItem = $obElement->GetFields(); $arItem['PROPERTIES'] = $obElement->GetProperties(); $data[$arItem['ID']] = $arItem; } |
|
|
06.03.2011 20:52:57
Но в общем да, не стоит брать в голову. |
|||||
|
06.03.2011 19:13:22
|
|||||
|
04.03.2011 22:13:53
Я правильно понял, что "DESCRIPTION" в вашем случае - это такой символьный код свойства и он у вас почему-то не изменяется?
И вместо такого подхода:
я бы использовал такой: CIBlockElement::SetPropertyValuesEx($idvalprop, IB_SUP_PRODUCT_PROPERTY_VALUE, $PROP); |
|||
|
03.03.2011 05:20:49
Нет, это значение вам ничем не поможет, т.к. является зашифрованным контрольным словом, из которого восстановить оригинальное значение нереально.
А метод CUser::ChangePassword() предназначен в основном для публичной части, т.к. он вызывает CUser::SendUserInfo(), который уже отправляет почтой настоящее контрольное слово (из 8 символов). Вам же, если я правильно понял вашу задачу, для смены пароля следует использовать просто |
|
|
03.03.2011 04:53:55
|
|||
|
25.02.2011 17:51:20
|
|||||||||||
|
23.02.2011 03:04:27
Проверку по свойствам предлагал вторым вариантом. Он наиболее удобен, когда есть стационарные колонки с одинаковым набором компонентов и в некоторых разделах сайта колонку нужно полностью отключать. Только реализация может быть несколько сложна, если "моргает" левая колонка в header.php и нужно учитывать свойства страницы, а не только для раздела.
|
|||
|
22.02.2011 23:04:59
Шаблон для демонстрации вывода колонок через компонент bitrix:main.include:
Штатный компонент подходит не по всем параметрам для нормальной реализации данной задачи, поэтому в идеале его нужно модифицировать, что для программиста не составит особого труда. |
|
|
22.02.2011 19:44:40
Или вы из тех интеграторов, кто считает, что меню и прочие стационарные компоненты нужно делать прямо в шаблоне сайта? (навидался вдоволь таких сайтов)
|
|||||||
|