1. Неформатированный код - это очень дурной тон. Особенно если приводите его с желанием получить ответ. 2. О каком кешировании идет речь? В приведенном примере система кеширования битрикс вообще ни как не задействована. 3. Чем вас стандартные компоненты не устроили?
Важная информация по модулям обмена, В этой теме будет выкладываться интересная и важная информация по модулям обмена с 1С:Предприятие. Просьба не флудить.
При загрузке из 1С каталога в справочники (HL блоки) заносятся необходимые значения. При этом им задается "безумный" XML_ID из которого, дальнейшем генерируется ЧПУ умного фильтра. Есть какойто "стандартный" механизм повлиять на это? (Чтоб и дальнейший обмен не нарушался, и чпу был понятным)
Александр Павлов написал: В документации по API оформления заказа все есть + можете разобрать сам компонент оформления заказа.
Это все понятно. По большому счету "нет ни каких проблем" вообще написать свою CMS, Можно все делать исключительно на старте..... Это все понятно... Даешь каждому фрилансеру свой велосипед. Чтоб уж получил клиента и фиг он от тебя свалил...
По этому, прежде чем строить свои велосипеды в любой не понятной ситуации, лучше попробовать обсудить с компанией Битрикс. В конце концов повышение ценника интеграции не идет на пользу в деле привлечения клиентов. (ни нам ни Битрикс). Да, к сожалению, тема забита пустыми нападками, и конструктива мало. А от сотрудников Битрикс, к сожалению, в основном: "Мы создали великолепный компонент, убеждайте в этом своих заказчиков или меняйте сами ибо 'тыжпрограммист'"
Учебные курсы и документация не помогли решить проблему Я понимаю, что вопросы изменения дизайна и доработка функционала не решаются техподдержкой
Ответ дан исключительно опираясь на данные доступные в документации. Я не знаю как принято в Битрис, но на мой взгляд знать ответы на подобные вопросы не обязательно для ТП первого уровня.
А при чем тут init.php? Файл подключается раньше, а обработчик события гораздо позже вызывается, тогда уже есть переменная $GLOBALS['USER'] (она же $USER). То что реализация обработчика описана в init.php (кстати, я бы рекомендовал выносить в отдельные файлы, и пользоваться функцией автозагрузки классов при обращении) не означает что метод выполняется в момент подключения файла.
Дмитрий Чебыкин написал: Как я понял, обуславливать обработку для OnBeforeIBlockElementUpdate в зависимости от пользователя, все равно нельзя (или нет?).
Можно... Просто тогда условие видоизменяется: конкретного пользователя всегда считать процессом обмена.... Это отличается от исходного
Цитата
Дмитрий Чебыкин написал: Если так, то нельзя ли сразу пользователя (считаем, что для обмена у нас отдельный пользователь) на хите определить и задать аналогично $inExchange
Если. Конкертный пользователь означает обмен и только обмен, тогда и проблемы то нет. Переменная $inExchage совсем не нужна - просто анаизируем текущего юзера...
нет не проверял. согласно документации OnBeforeCatalogImport1C - событие, вызываемое перед началом процедуры обмена: перед загрузкой XML в базу данных после загрузки файла на сервер. (т.е. это то же этап D) OnSuccessCatalogImport1C - событие, вызываемое после окончания обмена одним XML-файлом
Т.е. вполне логично, что между этими двумя событиями и происходит работа с элементами инфоблока. Т.е пришел следующий файл - опять возникает эта же последовательность событий. Хотя несколько стал менее уверенным в методе - надо проверять - добавить в этиобработчики вывод в логфайл - да убедиться.
Да вполне рабочий вариант и с кастомизацие файла 1c_exchange.php. Сделать переменную ExchangeHandlers::$inExchange Это даже лучше чем мой. Я бы сделал так: создал файл my_1c_exchage.php в нем устанавливал флаг из моего кода и дальше инклуд битриксного. 1Ску настроить на my_1c_excahnge.php
Если коротко: общение с веб сервером это не постоянный канал связи. А передача запроса серверу и получение от него ответа. (Хит). На каждом (абсоютно) хите переменная $inExchange будет равна false. Даже если в параллель будет 100 обменов идти. И лишь при появлении события OnBeforeCatalogImport1C оно будет изменять на true. И значение это будет изменено только и исключительно в рамках данного хита. Это, даже, не переменная сессии, не говоря о том что она ни как не связана между хитами разных клиентов. Если произойдет обрыв...... То будет просто обрыв хита.... все. Данная переменная и ее новое значение (если не будет багов ПО сервера) будет удалено из памяти (или точнееэта область будет помечена как свободная)
1. Если обмен прервется, то и событие OnBeforeIBlockElementUpdate не будет больше происходить. Следовательно необходимость в этом флаге отпадет.. Так что тут вообще нет ни какой проблемы абсолютно.
2. Ни чего не будет. По скольку сточки зрения сервера это разные хиты. Соответственно $inExchange будет у вас разное. Так что и тут нет ни каких проблем.
Прежде чем бочку катить на битрикс со своим анекдотом, вы бы вспомнили как работает PHP на веб сервере. И подумали как работает вышеприведенный код...
class ExchangeHandlers
{
private static $inExchange = false;
/**
* Обработчики событий модуля catalog
*/
public function OnBeforeCatalogImport1C($arParams, $file) {
self::$inExchange = true;
)
public function OnSuccessCatalogImport1C($arParams, $file) {
self::$inExchange = false;
}
/**
* Обработчики событий модуля iblock
*/
public function OnBeforeIBlockElementUpdate(&$arParams) {
if (self::$inExchange) {
}
}
}
И кстати, вот этот код вызывает сомнения в целесообразности: Я может не вижу подвоха, но мне кажется автор тут поучает значения, которые есть в $arFields. т.е. весь этот код сводится к $arRes = $arFields
Кроме того. Этот метод должен выполняться при добавлении в ИБ с ИД = 10. А тут запрос (из кода, что я процитировал) выполняется при добавлении раздела в любой ИБ. Единственное,что спасает - присутствие в фильтре значения из первичного ключа (да и то, стоит последним в фильтре - остается надеяться что сервер план правильно построит - хотя в большинстве случаев, думаю, так и происходит. но, тем не менее - лишний запрос)
"получаем список разделов эталона запчастяй" - это вообще имеет смысл кешировать
В приведенном коде, как минимум, смущает, что у вас каждый раз на каждом хите подключаются модули catalog и iblock Второе: если отсортировать по LEFT_MARGIN можно добавить за один цикл все уровни. А тут разделено на три уровня, да еще со вложенными циклами... бррр.
Да и вообще не очень понял зачем это копирование структуры. Но тут уже надо вдуматься в задачу.
Достаточно было подключить модуль sale. Именно в этом методе. По сути, при подключении корзины, вы подключили его... Но это не правильно же, когда один элемент неявно зависит от наличия другого. Т.е. если битрикс 14.0 или выше