404 мембера. Однако

Я не нашел

ht,zn

ребят

/** * Sets a list of filters for WHERE clause * * @param array $filter * @return Query */ public function setFilter(array $filter) { $this->filter = $filter; return $this; } /** * Adds a filter for WHERE clause * * @param string $key * @param mixed $value * @return Query */ public function addFilter($key, $value) { if (is_null($key) && is_array($value)) { $this->filter[] = $value; } else { $this->filter[$key] = $value; } return $this; }

зацените эдд филтер

какй костыль

или его вижу только я?

А в чем костыль?

скорее не костыль, а бага.. скорее всего должно было быть $this->filter = array_merge($this->filter, $value)

Ох уж этот ваш php...

костыль в том, что функция ждет два параметра. при чем первый должен быть стринг

хотя.. возможно это для сложной логики было сделано.. хм.. интересно было бы посмотреть где применяеться с $key=null

ну мне сейчас нужно

я надеялся метод принимает массив

придется юзать через костыль

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

if (is_null($key) && is_array($value)) вот это я считаю костыль

Типа ключик не может быть нулом?

вот и получается.. что это возможно для сложной логики filter=> ["LOGIC"=>"OR", 0=>$arFilter1, 1=>$arFilter2] чтоб такое собрать к примеру

странно было бы для такого key передавать 0 и 1

но это лишь предположения.. надо смотреть где применяется key=null

здесь надо применять массив.

* @param string $key надо просто заменить на * @param string | null $key и сразу все ок будет гыгы

ну да, надо ..

такие вещи обычно бывают когда - сначала один говорит, да что там такого, все просто же.. быстро внедряют, используют в 10+ местах а потом вспоминают про "незначительный нюанс"

а вообще в битриксе есть более ржачные места.. это да )

$query->addFilter('=GS.SITE_ID', $siteId); $query->addFilter(null, array( 'LOGIC' => 'OR', '=VISIBLE' => 'Y', '<=UG.ROLE' => \Bitrix\Socialnetwork\UserToGroupTable::ROLE_USER ));

ну вот.. сложная логика, почти слово в слово.. почему я не удивлен

а ключа нет - т.к. там должно быть число.. иначе битрикс не работает в другом месте затычка стоит) гыгы да и не считать же.. количество предыдущих вызовов, иначе будет третья затычка )

хотя логичнее конечно было бы зарезервировать слово key=>complexFilter к примеру.. хм

А завтра!!!!

ага.. восьмая уже.. а послезавтра девятая )

Всем хорошего вечера ребят!

есть каталог с разделами и элементами. как можно забубенить слайдер так, чтобы на каждый раздел можно было задать свои слайдеры?

доп.свойство секции?

да что-то тяжко даётся, надо в разделе показывать и в элементе

и доп.логика - дернуть текущую секцию или ее родителей, пока не найдем хоть чтото заполненное один минус - в корне слайдер так не задать

но в корне тогда только доп.галками в самом элементе.. как то так

а в чем проблема - у элемента также есть секция.. у элемента же слайдер секции показвыаем, верно?

да

ну вот.. в карточке товара есть section_id, логика не меняется

если у раздела есть подразделы, то тут получается надо будет еще и проверять есть ли у раздела родитель?

нет, ни в коем случае

надо логику утвердить другую

на секцию даем элементы, если на подсекцию в слайдере другие элементы - надо заполнить, если нет, не трогать

Спасибо всем большое, все сделала, хорошего вечера!

тогда получается - дергаем секцию, есил чтото есть, в слайдер, если нет - тогда только дергаем родителя

объединять эти массивы нельзя

Василий, на ты можно?

Отдельный инфоблок ? с привязкой к секциям

Василий, на ты можно?

не мона, а нуна

а ты где работаешь?))

infospice.ru

просто вещи ты дельные говоришь

интересно стало

хотя.. возможно это для сложной логики было сделано.. хм.. интересно было бы посмотреть где применяеться с $key=null

когда во втором аргументе ты передаешь массив фильтров, то первый аргумент ставишь в null

ну мне сейчас нужно

так и вводи setFilter(null,массив_с_фильтром)

просто вещи ты дельные говоришь

Пойдем в команду, мы эти вещи делаем

А не только говорим. Свету проще будет на новый плакат раскрутить )

когда во втором аргументе ты передаешь массив фильтров, то первый аргумент ставишь в null

Когда хочешь в фильтр многомерный, так будет точнее

да я не особо разработчик, в преоктировщики ушел, проекты еще просто тянутся, где просят что-то сделать и от денег отказываться думаю глупо

Когда хочешь в фильтр многомерный, так будет точнее

любой, даже из одного пункта

любой, даже из одного пункта

Нет

if (is_null($key) && is_array($value)) { $this->filter[] = $value; } setFilter(null,['=ID' => 100500]) работает

$class->addFilter('key', 'value'); $filter == ['key'=>'value']; $class->addFilter(null, ['key'=>'value']); $filter == [0=>['key'=>'value']]; вглядись внимательнее

ERROR: S client not available

там не merge массива

да я не особо разработчик, в преоктировщики ушел, проекты еще просто тянутся, где просят что-то сделать и от денег отказываться думаю глупо

на нет и суда нет.. но всеравно спсб за отзыв

там не merge массива

Несколько массивов работают как AND, если в массиве 1 элемент, то битрикс скушает и применит фильтр '=ID' => 100500, просто в запросе будут двойные скобки WHERE ((ID=100500))

я не говорю что нельзя собрать конечный запрос идентичный простому я говорю лишь о том что оно немного для другого - а именно для сложной логики и массив $this->filter отличается, т.к. логика сбора другая

в простом, без null ты логику or не соберешь

в простом, без null ты логику or не соберешь

не, эт понятно, я ж про то и говорил

с null без LOGIC явно обнозначенной работать не будет просто забыли "небольшой нюанс", либо собирались делать отдельный инструмент, а потом передумали

с null без LOGIC явно обнозначенной работать не будет просто забыли "небольшой нюанс", либо собирались делать отдельный инструмент, а потом передумали

вроде работает. без LOGIC все считается AND

ну тут скорее речь о том что будет когда несколько раз addFilter вызовешь вроде при нескольких без LOGIC уже не сработает

или я не прав? хм

работает работает

хыыы

"это битрикс, детка, в жопу логику"

ну спасибо, буду знать

нефиг наезжать, очень удобно. Когда компонент через класс делаешь. заводишь поле $baseQuery в куче методов добавляешь по условиям addFilter, причем и a,b и null,arX потом делаешь $q1 = clone $this>baseQuery; $q1->addSelect('CNT', ....) $q1->exec() общее кол-во $q2 = clone $this>baseQuery; $q2->setSelect([туева хуча полей]); чтобы два раза не вставать

хм

подумал еще раз - и решил что массив както привлекательнее нового непонятного объекта.. видимо я не познал дзен.. хм

подумал еще раз - и решил что массив както привлекательнее нового непонятного объекта.. видимо я не познал дзен.. хм

собирай фильтр, юзай getList внутри он все равно выполняется через query. Так что выигрыша/проигрыша особого нет

ну это понятно, и этот метод мне больше нравится

просто я не особый сторонник подхода винды - когда одно и тоже можно 10 разными способами сделать, причем совершенно разными и по совершенно разной логике и въезжать сложнее на поддержке, и дообучать

и тут как раз вопрос о том - был бы гдето выигрыш в читаемости, или скорости.. а тут просто сахар

причем весьма сомнительный

query - это для ООП-шников. Я например делаю компонент на классах. Базовый класс уже содержит всю логику запроса, а в потомках в две строчки добавляю фильтры, которых не достает

ну это то понятно

Ну и опять же ))) UNION можно получить только через $query1->getQuery . ' UNION ' . $query2->getQuery

но тут опять же.. или я стал стар, или действительно такой подход не самый хороший неявностями очень попахивает.. но это скорее общий недостаток ооп, если завернуть в более чем три слоя наследования - источник ошибки хрен найдешь в классах впринципе - это допустим хоть както оправдано в компонентах вывода .. оправдано ли.. а хз на самом деле, но дебажить будет сложнее, поддерживать тоже сложнее, т.к. хз сколько еще ссылаются код имеет несколько совершенно разных подходов одно радует - без работы лично меня это еще долго не оставит

union зло в чистом виде )

а, ну да.. волшебное слово, имхо )

> в компонентах вывода .. оправдано ли.. ну например, у меня куча компонентов выводящих отчет по разным данным, у всех запросов джоинится несколько одних и тех же справочных таблиц, различаются только таблицы с данными. Фильтры одни и теже (дата, юзер, и т.д) Базовый запрос я формирую в одном базовом классе, где через queryформирую весь фарш кроме селекта, метод вызова запроса, вызов шаблона, валидацию входящих параметров и т.д. потом делаю десяток компонентов-потомков, в которых всего 1 (один) метод $this->baseQuery->addSelect() и свой шаблон

> различаются только таблицы с данными чистой воды параметр компоненты

если оно действительно так просто как ты написал несколько свойств с названиями таблиц выглядят несколько более привлекательно чем несколько компонент..

зато когда в одном из 10 надо будет переписать функционал, то я только в нем переопределю пару методов