Артём Дубин (Все сообщения пользователя)

Без изменений? Плохо.

Археологи в треде
По ид, конечно, быстрее, но в ряде случаев решение через классы сильно упрощает код (в том числе и серверный - не надо генерировать итератор для уникальных идентификаторов и т. п.), поэтому тут сильно подумаешь, чуть нагрузить пользовательскую машину или добавить лишний десяток строк по сути ненужного кода.
Да и вообще, за прошедшее время многое изменилось как в js - так и в BX. Сейчас я всё больше склоняюсь к мнению что с jquery пора прощаться.

Редирект, не, не слышали?

Это не все прелести: выяснилось что если заказ от незарегистрированного пользователя - то могут быть созданы 2 пользователя вместо одного. Ну и двойное нажатие не может порвать заказ на 2 части.

PHP7, штатный компонент.
При нажатии кнопки "оформить заказ" выводит сообщение что заказ успешно создан, вроде всё нормально, НО:
Открываем админку, идём в заказы и видим что заказа 2, причём часть товаров в первом, часть во втором.
Срабатывает это не всегда, выявить закономерность по такой ошибки, а также по какому принципу делятся товары на 2 заказа не получилось.
Техподдержка заявила что ошибок нет.

Никто с таким не сталкивался?
Нет ли у кого рецепта как это победить?

Что мы имеем в сухом остатке: вы у себя на портале ведёте ту работу которую я предлагаю сделать разработчикам компонента.
Только очевидно что разработчикам это сделать проще (у них структура обмена всегда под рукой так как они с ней работают и её же постоянно дорабатывают).
А также очевидно что логичнее если это делает один человек, а не все студии-партнёры персонально для себя.

Только я не понимаю, для чего в таком случае строить из себя д'Артаньяна и намекать на свою высокую квалификацию, если по факту вы делаете то же самое что предлагаю и я? Детский сад.

Примерно так и думал. Если под рукой была бы документация - то можно было бы уложиться в день написанием своего шаблона с нуля.
А это сэкономленные деньги. Сильно подозреваю что мусорного кода от стандартного шаблона тоже много осталось.
Плюс не забываем оговорку что до этого вы долго расписывали функции что они делают (документацию по которым я и прошу опубликовать разработчиков компонента), а это тоже время, потраченное на изучение чужого кода.
Плюс не забываем, что данную работу придётся проделать снова если компонент сильно измениться.
Так что единственный плюс от вашего подхода - это то что вы с гордостью можете заявить о том что смогли разобраться в этом компоненте (в отличие от некоторых).
Ссылочкой не поделитесь?

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

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

Понятно что работа компонента основана на api битрикса, но как работает сам компонент?
Он принимает запросы от sale.order.ajax.js и в ответ выдаёт данные. То есть формирует свой уровень api, и описать его не очень сложно (компонент ждёт данные в таком-то формате - а в ответ выдаёт в таком), а вот вычленить это из скрипта тяжело, да и если компонент обновиться то придётся делать всё заново.
А если есть api компонента - то открываешь документацию по нему и читаешь: "с такого то дня компонент принимает новый параметр id_parametr, в ответ выдаёт id_response", после этого идёшь в свой шаблон и добавляешь новую фишку. Потратил 10 минут от силы - и всё.

Просьба выложить api работы компонента - это конструктивное предложение, а не нытьё.

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

Тяжеловато. может через фильтр как-то можно?

Добрый день.
Можно ли как-то получить идентификатор раздела товара в заказе через CSaleBasket::GetList?

Да тут даже не функции описывать надо:
js штатного шаблона всё через аякс дёргает из компонента, достаточно описать структуру всех запросов и формат ответов (а главное поддерживать это в актуальном состоянии, чтоб не лезть в это скрипт и не расшифровывать по новой чего там изменилось).

Описание каждой строки кода несколько отличается от документирования api компонента, да и места много не займёт.  И самое главное её можно поддерживать в актуальном состоянии.
Поможет это очень сильно, особенно при разработке своего шаблона с нуля.
Ну и разобрать как работает та или другая функция с помощью такой документации гораздо проще.
Ну а такому высокомерному гению как ты - то вообще 5 минут делов.

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

Молодец, возьми с полки пирожок.
Но сначала всё таки почитай что-нибудь по основам программирования.

Вы в код шаблона заглядывали? Там голая структура (пустая) и огромный js. А откуда js данные берёт?Мля, где здесь смайлик "рука-лицо". Я вам рекомендую прочитать хотя бы яваскрипт для чайников за 24 часа.Ну даже не знаю, начните отсюда: https://ru.wikipedia.org/wiki/API. Хотя нет, попробую разжевать, это должно выглядеть следующим образом:
Ну и так все доступные методы.БезусловноМожно, но такая практика ни к чему хорошему не приведёт, выше в этой теме много раз обсуждали почему, да и сами заказы стремительно меняются, так что обращение по api к актуальному компоненту - хорошее решение.Я уже всё понял о вашем профессиональном уровне. Честно говоря, сильно удивлён: третий год на сайте, активный пользователь, и ничему не научился.

Предлагаю голосовать: http://idea.1c-bitrix.ru/21639/

При чём здесь события компонента?
Если мы пишем свой компонент то нам надо:

1. Разобрать какие стартовые параметры необходимо заполнить чтоб компонент нормально стартовал (arParams);
2. Данный компонент тут же по аякс просит дефолтные значения по платёжной системе, доставки. Как он их просит (какие параметры надо отправить для запроса и каков формат ответа)?
3. Как запросить доступные доставки, оплаты, местоположения (какие параметры надо отправить для запроса и каков формат ответа)?
4. Если пользователь изменил оплату/доставку - то какие параметры надо отправить для изменения (какие параметры надо отправить для запроса и каков формат ответа)?
5. Как обновить список доступных оплат/доставок с учётом указанных пользователем настроек(какие параметры надо отправить для запроса и каков формат ответа)?

На самом деле такая выжимка займёт от силы пару страниц печатного текста, но позволит за день написать свой шаблон с нуля.
А события php и js тут совсем не причём.

Разработчики - может опубликуете?

Отлично. Вы не могли бы поделиться с сообществом документацией по протоколу обмена с компонентом?
Ну типа набор параметров А,Б,С меняет доставку, А,Б,Д - способ оплаты, требуется названия параметров, необходимый набор параметров для смены каждого параметра заказа, типы отправляемых данных, какие параметры нужно отправить при старте компонента и т.п.
Та же просьба к разработчикам: может опубликуете эту информацию?

У меня не работает для незарегистрированных пользователей. Причём если зарегистрировать на месте - то не помогает.

Антон Дегтярёв,
Ищи функцию "getPropertyRowNode:", после "switch (propertyType)" в неё впиши примерно следующее:

Кстати, относительно темы топика: не раз ловил себя на мысли когда модифицировал этот компонент, мол вот было бы событие "on" в bx, насколько бы код был лаконичей, не надо бы было пересоздавать объект компонента после каждого тыка пользователя на доставку, оплату и прочее.

Jquery позволяет цепляться не только по классам, но и по атрибутам, по атрибутам с определёнными значениями, по разным их сочетаниям, имеет более лаконичный механизм по работе с событиями. Всё это в сумме делаем его более практичным и эффективным инструментом, а то что написать можно через одно место - так это и на bx можно, как раз в приведённой мной теме один такой пример и разобран (это где предложено вешать идентификатор на body).