Форум

Интересным  дополнение  к  этой  теме  есть то, что  поле XML_ID,  по  которому  идут  абдэйты  элементов,  отнюдь не  уникальное.  Теоретически оно  может  быть  пустым  или  одинаковым  у  всех  элементов,  всех  инфоблоков.  :)

Спасибо  за  ответ.
да,  я  тоже  чет  нашел  в  запросах  подтверждающее, что  поле  XML_ID  физически  существует,  а EXTERNAL_ID  его  "ассоциация".
SEL ECT BPE.*, BPE.XML_ID as EXTERNAL_ID FR OM ...
Но  объясните  какой  смысл  в  этом?   Я  думал,  что  используя  EXTERNAL_ID  система  предварительно  проверяет  существует  ли   XML_ID  с  таким  именем  и  если  да  то  берет  к  примеру  ID  элемента  вместо  предложенного   EXTERNAL_ID.
Не  понятно  зачем  столько  имен..
"Он  же  Жора,  он  же  Длинный,  он  же....   :) "

Чет  не  нашел  инфы,  что  лучше  (или  точнее  в  каких  случаях)  использовать  XML_ID  и  EXTERNAL_ID?
Какая  между  ними  принципиальная  разница?
Иногда  еще  встречаются  поля  TMP_ID...

К  величайшему  сожалению  никто  не  желает  подсказать  «в чем  я  неправ».  Интересно что  сама  функция  которая  и  лежит  в  основе  вышесказанного  компонента  
$obSearch->Search($arFilter, $aSort, $searchFiltr);  
с  моим  фильтром  работает  без  проблем.  Поэтому  придется  кастомизировать  компонент.

Почему  не  работает: $searchFiltr = array("LOGIC" => "OR", array("%ITEM_ID" => '/ru/about/') , array("PARAM2" => 2));  ?

Так  нам  не  нужно  ограничивать  область  поиска  инфоблоками.  Там  должны  присутствовать  как  элементы  инфоблоков  так  и  статические  страницы.  Ограниченные  только  физическим   «разделом»

[QUOTE] Динамические? Ограничить область поиска инфоблоком или типом Инфоблоков.
[/QUOTE] Желательно всех инфоблоков которые только могут там лежать.
По  минимуму  нескольких  инфоблоков,   к  примеру:  "MODULE_ID" => "iblock", "PARAM2" => array(2,33,38)

Стоить  следующая  задача:  «Перестроить  стандартный  поиск   на  поиск  по  разделам  сайта».  Под  разделами  сайта  подразумеваются  физические  разделы  типа  /ru/about/.
И  искать  нужно  всё  что  лежит  в  этом  каталоге  и  подкаталогах.
У  стандартного  компонента  есть  поле  где  указываем  название нашего фильтра: "FILTER_NAME"  => "searchFiltr",  Предварительно  объявляем   глобальную  переменную:  global $searchFiltr;  затем  создаем  фильтр:
$searchFiltr = array("%ITEM_ID" => '/ru/about/');  -  в  этом  случае  отфильтровываются  все  статические  страницы  лежащие  в  каталоге /ru/about/.
А  как  быть  с  динамическими?  Делаем  по  аналогии  описанной  в  доке: [URL=http://dev.1c-bitrix.ru/api_help/search/classes/csearch/search.php?print=Y]http://dev.1c-bitrix.ru/api_help/search/classes/csearch/search.php?print=Y[/URL]
$searchFiltr = array("LOGIC" => "OR", array("%ITEM_ID" => '/ru/about/') , array("PARAM2" => 2));  В  результате  получаем  всё,  что  есть  в  базе.
Как  правильно  построить фильтр  для  компонента  в  моем  случае?

:?: /news list/section1/section2/section3/section4/element id/
Как  всем  известно,  в  комплексном  компоненте  новостей  есть  возможность  между  списком  новостей  и  детальной  новостью  включить  страничку  раздела.  И  корректно  отобразить  её  в  ЧПУ и  навигационной  цепочке.
Но  «дерево»  разделов  может  быть  неограниченно  сложным.
Как  можно  создать  вложенные  (виртуальные)  страницы  такого  «дерева»,  где  в  конце  каждой  ветки  был бы  элемент  инфоблока?
У меня  получалось делать  вложенность на несколько уровней,  создавая  дополнительные  правила  обработки  адресов,  добавлять   пункты  в   навигационную  цепочку.  Но  это  убьёт  поиск  по  этим  страничкам.  Да  и  при  пересохранении  настроек  компонента,  могут  слететь  мои  правила  обработки  адресов.
Как  быть?

Так  как  теперь новый модуль версия 1.0.0 (14.08.2011)  не  работает  с  ПриватБанком ?