запрос: 2016-09-13T19:25:20.031845Z 1610 Query SELECT bars46_requests_card_cards_list.ID AS ID, bars46_requests_card_cards_list_props.PROPERTY_87 AS EMAIL FROM b_iblock_element bars46_requests_card_cards_list LEFT JOIN b_iblock_element_prop_s17 bars46_requests_card_cards_list_props ON bars46_requests_card_cards_list.ID = bars46_requests_card_cards_list_props.IBLOCK_ELEMENT_ID WHERE bars46_requests_card_cards_list.IBLOCK_ID = 17 ORDER BY bars46_requests_card_cards_list.NAME ASC

и никаких поднятий свойств

телеграм обратный апостроф превращает в зеленый шрифт оказывается )))

test 'test'

это чтобы код форматировать

echo "debug";

/help@TagRobot

Click here and start the bot. Then you can type /help

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

ОРМ: один getList - всегда один запрос, старый API один GetList - столько запросов, сколько понадобится движку, зависит от настроек и структуры инфоблока, особенно привязок других инфоблоков

Коллеги,подскажите,кто-то делал сортировку по цене с учётом скидок?

Коллеги,подскажите,кто-то делал сортировку по цене с учётом скидок?

для этого можно сортировать просто по основной цене. тк цены со скидками будут пропорционально меньше (веротяно).

для этого можно сортировать просто по основной цене. тк цены со скидками будут пропорционально меньше (веротяно).

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

Коллеги,подскажите,кто-то делал сортировку по цене с учётом скидок?

Скидок много?

В целом самих скидок ? Или товаров у которых они есть ? Просто тут знакомые говорят, битрикс фуфло и тормозит жутко, а на вопрос, вы хоть поддерживаете и ращвиваете магазин-будет ответ нет. И еще не нравятся что сортировка по цене с учётом скидок не раьотает

В целом скидок нормально и они разные для каждого товара

Ну костыль, например. Отсортировать полученный массив arItems по OPTIMAL_PRICE, тогда будет адекватная сортировка в пределах страницы

Если скидок мало, то можно убрать скидки и сделать несколько цен уже со скидкой и сортировать по цене, доступной конкретному юзеру

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

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

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

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

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

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

согласен согласен

в общем из коробки нет сортировки (и фильтра тоже) по скидочным ценам, тк они вычисляются на лету

это уже очень старая проблема

Ну и чисто визуальное решение. Если будет выводится Розничная цена + "а для вас это будет стоить ХХХ", то можно сортировать по розничной и юзеры будут не особо возмущены

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

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

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

значительно различаться сортировка с учетом скидки, я хотел сказать

вот вот, и я об этом писал)

Проблема обычно в правилах применения скидок помимо пользовательской. Типа вновь зареганным пользователям скидка 2% на товары дороже 5000, исключая товары по "лучшей цене"

это лучше к корзине прикручивать

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

Заказчик хочет это показывать сразу в каталоге, ибо маркетинговый ход

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

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

на погрешность сортировки можно забить в этом случае

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

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

кстати, точно - можно просто писать в каталоге "а для вас будет скидка 2%", и не вычилсять ее вообще)

единственный раз я видел где не то что скидки были индивидуальны индивидуально пользователям можно было назначать цены но это был не магазин отнюдь, и цены действительно считались конкретно для пользователя в НАВе

а каталог закрыт, да

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

Заказчика тоже понять можно. Есть сегменты, где наценка минимальна и даже комиссия Яндекс-денег, может сожрать прибыль. И заказчики выгадывают, выискивают. Чтоб и скидку лояльным, и маркетинг, и чтобы не прогореть. Там алгоритмы те еще.

а что мы сейчас уже обсуждаем?)

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

Болтаем на сон грядущий.

Заказчика тоже понять можно. Есть сегменты, где наценка минимальна и даже комиссия Яндекс-денег, может сожрать прибыль. И заказчики выгадывают, выискивают. Чтоб и скидку лояльным, и маркетинг, и чтобы не прогореть. Там алгоритмы те еще.

да знаю.. слово маржа для меня не матерное :)

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

ахаха, но это уже тема для совсем другого чата )

кстати.. у юлмарта судя по тому что я видел в стилях - было 6 или 7 маркеров сейчас 3 :)

это так.. к слову )

маркеры это "новинка", "хит" и тд?

нет, это по программе такса - процент скидки

просто и понятно, берешь с этим кружочком получаешь такую скидку, а с другим другую :)

и фильтр по кружочкам есть.. мне понравилось

как пользователю понравилось, более того я даже "повелся" и купил себе блок питания дороже чем собирался но зато с большей скидкой ? фильтр сработал ?

Есть еще вопрос на засыпку, по битриксу) вот в старом CIblockElement::getList можно было указать поле DETAIL_PAGE_URL и получить заполненный шаблон. как это сделать в новом апи ElementTable ? если там указать поле DETAIL_PAGE_URL - ругается "не знаю такого поля", и это понятно почему. Как заполнить этот шаблон, так сказать "в одну строку кода"?

тонко :)

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

присоединить IblockTable в runtime

и там мы получим только шаблон

а еще его надо заполнить

и из шаблона пути - оно само простроит? да ладно?

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

присоединить FileTable в runtime )))

кроме шуток

ERROR: S client not available

там нет реального src с учетом нахождения папки upload, точнее не должно быть

и из шаблона пути - оно само простроит? да ладно?

Дмитрий?

$params['UPLOAD_DIR'] = Main\Config\Option::get("main", "upload_dir", "upload");

'runtime' => [ new Main\Entity\ReferenceField( 'PREVIEW_PICTURE_FILE', 'Bitrix\Main\File', array( '=this.PREVIEW_PICTURE' => 'ref.ID' ) ), new Main\Entity\ReferenceField( 'DETAIL_PICTURE_FILE', 'Bitrix\Main\File', array( '=this.DETAIL_PICTURE' => 'ref.ID' ) ), new Main\Entity\ReferenceField( 'PROPSS', 'Bars46\Site\Components\ComponentPropsS', [ '=this.ID' => 'ref.ID' ] ), ],

парни, о чем вы?)

вернемся к DETAIL_PAGE_URL

не мешай флудить)

? ладно, молчу-молчу

Собственно на это и уходит та куча запросов, которую плодит CIblockElement::GetList

это понятно, но не вся туча кстати.

как теперь то быть? нет ответа?

Про шаблон?

пути

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

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

получить шаблон из b_iblock, а дальше str_replace #ID# на полученный ID

на шаг впереди))

в шаблоне же не только ИД элемента или его код. там еще может быть код или путь из кодов разделов.

ну так ОРМ и не должен все сразу делать, это для тех, кто хочет контролировать манипуляцию данными. Можно написать свои методы getЧегототам

да, кстати - путь из кодов разделов это сильно)

два запроса

на первом получить LEFT/RIGHT_MARGIN, а на втором GROUP_CONCAT секций

и потом переборка данных, да не, норм решение если выгода перевешивает а если выгоды нет - то гетлист и не выепываться )

Так в том то и дело, что там где можно обойтись гетлистом - не стоит лезть на низкий уровень с ОРМ, тем более, что они могут работать параллельно, благо ОРМ не позволит писать в инфоблоки

Вот когда понадобится составить список по инфоблокам, у которых вложенность "привязки к..." больше 2, то без ОРМ не обойтись

ОРМ - это конструктор запросов, представляя структуру таблиц как объект. Обработка полученных данных ложится на программиста

Ладно... https://www.youtube.com/watch?v=P5Y0iaUBRKY

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

хм.. реяльно а я бы не джоинил тут таблицу, а просто запросил запись инфоблока..

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

и на выхлопе - то на то и вышло.. только вместо компа отработал прогер но если путь простой и там правда или id или просто код - то все тогда и правда удобно кажется вроде так

апупенный доклад https://m.habrahabr.ru/company/oleg-bunin/blog/309878/