И интерфейс этого канала изменился.
Старый интерфейс представлял собой набор методов, имена которых записывались в поля соответствующего элемента корзины (для каждого элемента). Магазин по необходимости запускал соответствующие методы. Например, для актуализации цены и доступности товара он запускал метод из поля CALLBACK_FUNC, а при оформлении заказа - ORDER_CALLBACK_FUNC.
Для реализации нового функционала каталога и магазина 12.5 (складской учет, резервирование и отгрузка товаров,...) нам потребовалось существенно расширить интерфейс общения между каталогом и магазином. И экстенсивное расширение путем добавления в корзину новых полей с новыми именами новых функций было признано не эффективным.
Магазин продолжает поддерживать старый интерфейс в старом объеме функционала. Но с текущей версии общение магазина и каталога базируется на новом интерфейсе. И новый функционал тоже основывается уже на новом интерфейсе.
В корзину добавлено одно новое поле PRODUCT_PROVIDER_CLASS, которое содержит имя класса, реализующего интерфейс IBXSaleProductProvider. Этот интерфейс и определяет интерфейс общения магазина и сущностей, которые кормят магазин товарами. Каталог записывает в это поле имя класса CCatalogProductProvider.
Обратите на это внимание, если вы пользовались какими-то хаками, чтобы добиться нужного вам поведения. Возможно вам потребуется отнаследоваться от класса CCatalogProductProvider или сделать свою собственную реализацию IBXSaleProductProvider.
О чудо! Наконец начали документировать код! =)
Спасибо
Это относится к любому callback?
Я правильно понимаю, что с 12.5 всем данным доработкам кранты?
----------
новость то очень неприятная.
12 редакция, наверное, станет самой знаменитой по отказу от совместимостей и пересмотру и отказу от прежних стандартов.
другие времена - другие нравы.
То, что теперь названо хаком, когда то являлось официально документально описанным функционалом продукта и стандартом.
А как жарко обсуждалось на форумах....
есть один, на котором модуль каталог Битрикс не используется вообще по ряду причин и используется свое ценообразование.
есть такой, в котором цены вообще определяются из источников по протоколам SOAP а вот когда покупатель бросает в корзину товар, то работает именно с предложением внешнего сервиса (реально по callback проверяется наличие и актуальность цены)
есть такой проект в котором прайс листы вообще хранятся в отд. таблице, так как на один товар может существовать несколько различных предложений от различных поставщиков и т.д. и т.п, а прикручивать в 2009 году связанные элементы для неск. сотен тыс. позиций, данные по которым меняются неск. раз в день смысла я не видел.
это примеры реальных проектов, на которых callback в свое время понадобился
------------
Не вижу смысла обращаться за решением данных проблем в ТП
В любом случае диагноз ясен - перевод с доработкой
Но вот что теперь интересно - а новое то на какой срок станет стандартом?
-----------
Я еще раз подчеркну для чего писал все выше
Выходит вот такой простенький пост, который ставит крестик на некоторых проектах.
Ну не может быть, чтобы только я один из всех битриксоидов с кэлбеками в свое время поработал
А вот за то, что предупредили - спасибо.
будем внимательны
Если вы пользуетесь старыми колбэками, они должны успешно продолжить функционировать. Не будет функционировать только смесь из новых и старых.
На первый взгляд не верная работа у вас может быть только если вы заносили товар в корзину стандартным АПИ каталога, а потом в событии подменяли часть колбэков. Это что-то типа хака. В этом случае сейчас следует в событии стереть класс и записать все старые колбэки. И все должно работать по старому.
Если же вы заносили товар сами и он до сих пор заносится со старыми колбэками, то все должно работать и так.
Учитывая переезд на ORM и постепенный переезд всех модулей на D7, можно ли надеяться, то подобное решение будет и в других связках. Например, можно ли надеяться, что хранилище для каталога так же можно будет через класс-интерфейс подставлять свое?
Текущий интерфес предполагает, что между Интернет-магазином на платформе Битрикс и какой-то внешней ERP/WMS-системой происходит обмен информацией о цене/наличии товара и, соответственно, о покупке/отгрузке.
Почему не предположить ситуацию, что описание/картинка и характеристики товара для каталога на платформе Битрикс так же берутся из какой-то внешней БД через схожий интерфейс. Это позволит более гибко подходить к интеграции платформы Битрикс с внешними системами, и при этом использовать больше функционала, реализованного Вашими программистами в рамках стандартных модулей, например использовать тот же "Умный фильтр", сравнение и т.д.
Хотя конечно если изначально заложить поддержку этого, то решение может быть более красивым.
По вопросу из личной переписки:
если вы подменяли колбэки на событии добавления товара в корзину и не хотите делать сейчас поддержку нового функционала, то вам следует в вашем обработчике события грохнуть значение в поле PRODUCT_PROVIDER_CLASS корзины и добавить все старые обработчики. Т.е. не только те, которые вы подменяете, но и остальные. Что-то типа
с подменой нужных вам обработчиков
AddEventHandler("sale", "OnGetOptimalPrice", "MontageBasketAdd";);
function MontageBasketAdd(&$arFields)
{
$arFields['PRICE']="".$_REQUEST["pr"];
$arFields["CURRENCY"] = "RUB";
$arFields["CALLBACK_FUNC"] = "";
$arFields["ORDER_CALLBACK_FUNC"] = "";
$arFields["IGNORE_CALLBACK_FUNC"] = "Y";
}
если же ставлю
AddEventHandler("sale", "OnGetOptimalPrice", "MontageBasketAdd";);
function MontageBasketAdd(&$arFields)
{
$arFields["PRODUCT_PROVIDER_CLASS"] = "";
$arFields['PRICE']="".$_REQUEST["pr"];
$arFields["CURRENCY"] = "RUB";
$arFields["CALLBACK_FUNC"] = "";
$arFields["ORDER_CALLBACK_FUNC"] = "";
$arFields["IGNORE_CALLBACK_FUNC"] = "Y";
}
цена все равно не изменяется, как мне её изменить?
callback'ахв функциях класса по обработке позиций корзины можно будет оперировать наборными параметрами или ID самой позиции?Очень часто цена зависит не только от параметров товара как такового, а и от доп условий:
- Доп услуги к данной конкретной позиции
- Период подписки на данное издание
- Время продаваемой услуги
Давайте обсудим пожелания либо формате форума, либо в формате сайта идей. Не до конца понятно, как это в итоге должно работать, чтобы удовлетворить ваши нужды. Есть разные варианты реализации.
Примеры задач:
1) Есть базовая и льготные типы цен. Покупатель имеет доступ к обоим типам. Какой именно тип будет применяться зависит от галки во время покупки (те наборное свойство позиции корзины).
2) Продаем подписку. Количество в корзине - количество экземпляров. Есть цена на минимальный подписной период. Фактический период подписки покупателя складываем в свойства позиции. Те цена позиции зависит от фактического подписного периода.
3) К продаваемомой позиции можно привязать доп услуги. Например туры. Всякие виды обслуживания, стандарты питания, классы отелей, доп экскурсии и т.п. - дополнительные опции одной позиции, которые меняют ее стоимость
И так далее.. примеров в работе уже массу накопили.
Получаем, что стоимость позиции зависит от ее наборных параметров.
Один раз определить стоимость и сложить все в корзину - проблем нет. Но вот вызов стандартных callback-ов или, как теперь предлагается, методов класса убивает всю логику построения стоимости позиции.
В самх callback-aх, а теперь и в методах класса, нет возможности обратиться к позиции корзины как таковой, как следствие не можем получить наборные параметры позиции, ну и в конце просчитать актуальные цены.
Те предлагается:
раз уж вывели в новый канал механизм поддержания актуальности цен и остатков, то добавьте в нем возможность работать с текущими данными позиции. Вполне достаточно ID позиции.
Вот стандартный вызов в CAllSaleBasket::ReReadPrice, CAllSaleBasket:: OnOrderProduct и CAllSaleBasket:: UpdatePrice
if (CSaleBasket::GetProductProvider(array("MODULE" => $module, "PRODUCT_PROVIDER_CLASS" => $productProvider))) { $arFields = $productProvider::GetProductData(array( "PRODUCT_ID" => $productID, "QUANTITY" => $quantity, "RENEWAL" => $renewal )); } else { $arFields = CSaleBasket::ExecuteCallbackFunction($callbackFunc, $module, $productID, $quantity, $renewal); }и тут действительно не тема для этого. читайте документацию или форум, уж по колбэкам на форуме примеров полно.
Спасибо.
CALLBACK_FUNC и ORDER_CALLBACK_FUNC подменяю своими, в CANCEL_CALLBACK_FUNC и PAY_CALLBACK_FUNC прописываю стандартные. В PRODUCT_PROVIDER_CLASS ставлю false.
Если товар, добавленный таким образом, редактировать в заказе в админке, то при уменьшении количества в заказе, количество на складе не увеличивается. И при удалении товара из заказа тоже не увеличивается. А ведь должно. Попробовал вместо CALLBACK_FUNC и ORDER_CALLBACK_FUNC тоже поставить стандартные Битриксовые, не помогло. Количественный учет включен.
Номер обращения в техподдержку - 389950.
Например, используем Add2BasketByProductID(144, 1, array('NAME' => 'Товар', 'SUBSCRIBE'=>'Y'), array());
Если 'SUBSCRIBE'=>'Y', то имя товара берется из параметра 'NAME' => 'Товар'
, соотвественно, если 'SUBSCRIBE'=>'N' , то игнорируется параметр 'NAME' и имя товара берется из описания товара (инфоблока).
PRODUCT_PROVIDER_CLASS для всех добавляемых товаров в корзину? Или нужно лезть во все места где вызывается CSaleBasket::Add?
Код примерно такой получился :
EventManager::getInstance()->addEventHandler("sale", "OnSaleBasketItemBeforeSaved", "onSaleBasketItemBeforeSaved" ); function onSaleBasketItemBeforeSaved( Main\Event $event ){ $item = $event->getParameter("ENTITY"); $item->setFields( array("PRODUCT_PROVIDER_CLASS"=>"CCatalogProductProviderCustom") ); $result = new Main\EventResult( Main\EventResult::SUCCESS, array("ENTITY", $item) ); $event->addResult($result); }Bitrix\Main\EventManager::getInstance()->addEventHandler("sale", "OnSaleBasketItemBeforeSaved", "OnSaleBasketItemBeforeSavedHandler" ); function OnSaleBasketItemBeforeSavedHandler(\Bitrix\Main\Event $event ) { $item = $event->getParameter("ENTITY"); $item->setFields( array("CURRENCY"=>"RUB") ); $result = new \Bitrix\Main\EventResult( \Bitrix\Main\EventResult::SUCCESS, array("ENTITY", $item) ); $event->addResult($result); }