Новый sale.order.ajax

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

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

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

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

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

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

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

Роман Павленко, Свойства отображаются только для нужных свойств, но отображаются не там!
Вопрос именно в том, чтобы вынести свойства из блока с информацией о пользователе в отдельный блок.
Зачем свойства, привязанные к той или иной доставке в блоке о пользователе? Считаю, что не нужны...

Сергей Панчук, почему в блоке пользователя?
К примеру, свойство, отвечающее за точку выдачи товаров у службы доставки. Это обычный список из точек, привязанных к конкретному местоположению. Было бы логично такое свойство помещать в системный блок со складами, а не в блок с информацией о пользователе...

поправьте меня пожалуйста - НО работа компонента построена не на ajax
компонент он и есть компонент - работает на php

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

если надо делать свой шаблон - то, что Вам мешает - есть результирующий массив, который возвращает компонент в шаблон!
и что значит API компонента???
компонент работает на API 1С-Битрикс

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

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

бляха муха спец нашелся... который не может разобраться как блин в js данные передаются!!!

ПИСЕЦ!
я кончил!

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

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

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

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