Цитата |
---|
Юрий Стрельцов написал: Здравствуйте, кто-то убирал способы оплаты полностью в новом order.ajax ? |
11.02.2017 19:32:56
|
|||
|
|
13.02.2017 13:48:38
затишье-то какое))) видимо, все в трудовом поту - переносят все свои наработки и верстки в нового монстра))) вернее, пытаются)))
|
|
|
|
15.02.2017 19:55:55
Если вам не нравится новый шаблон - сделайте свой. Главное что бы все данные отправлялись в нужных ключах, и происходила перезагрузка страницы через ajax при выборе местоположения\доставки\оплаты. |
|||||
|
|
16.02.2017 00:23:23
|
|||
|
|
16.02.2017 05:44:01
Ну типа набор параметров А,Б,С меняет доставку, А,Б,Д - способ оплаты, требуется названия параметров, необходимый набор параметров для смены каждого параметра заказа, типы отправляемых данных, какие параметры нужно отправить при старте компонента и т.п. Та же просьба к разработчикам: может опубликуете эту информацию? |
|||
|
|
16.02.2017 06:17:10
а так: события компонента оформления заказа (события php и события js) этого вполне хватает для этого! |
|||
|
|
16.02.2017 06:34:31
Если мы пишем свой компонент то нам надо: 1. Разобрать какие стартовые параметры необходимо заполнить чтоб компонент нормально стартовал (arParams); 2. Данный компонент тут же по аякс просит дефолтные значения по платёжной системе, доставки. Как он их просит (какие параметры надо отправить для запроса и каков формат ответа)? 3. Как запросить доступные доставки, оплаты, местоположения (какие параметры надо отправить для запроса и каков формат ответа)? 4. Если пользователь изменил оплату/доставку - то какие параметры надо отправить для изменения (какие параметры надо отправить для запроса и каков формат ответа)? 5. Как обновить список доступных оплат/доставок с учётом указанных пользователем настроек(какие параметры надо отправить для запроса и каков формат ответа)? На самом деле такая выжимка займёт от силы пару страниц печатного текста, но позволит за день написать свой шаблон с нуля. А события php и js тут совсем не причём. Разработчики - может опубликуете? |
|||
|
|
16.02.2017 09:30:34
Если кратко - настраиваете привязку свойств заказа к платежным системам и службам доставки. Тогда привязанные свойства будут отображаться только при выборе соотвествующего варианта платежки/доставки. |
|||
|
|
16.02.2017 11:18:38
Роман Павленко, Свойства отображаются только для нужных свойств, но отображаются не там!
Вопрос именно в том, чтобы вынести свойства из блока с информацией о пользователе в отдельный блок. Зачем свойства, привязанные к той или иной доставке в блоке о пользователе? Считаю, что не нужны...
"Не нравится - критикуй, критикуешь - предлагай, предлагаешь - делай, делаешь - отвечай."
Сергей Павлович Королёв |
|
|
|
16.02.2017 11:21:50
Алексей Попович, Я считаю что логично когда меняется информация именно в блоке пользователя. Просто вам поставили такое тз и его нужно сделать. Если у кого-то есть опыт по такому тз - поделитесь.
|
|
|
|
16.02.2017 11:24:33
Сергей Панчук, почему в блоке пользователя?
К примеру, свойство, отвечающее за точку выдачи товаров у службы доставки. Это обычный список из точек, привязанных к конкретному местоположению. Было бы логично такое свойство помещать в системный блок со складами, а не в блок с информацией о пользователе...
"Не нравится - критикуй, критикуешь - предлагай, предлагаешь - делай, делаешь - отвечай."
Сергей Павлович Королёв |
|
|
|
16.02.2017 11:34:50
Предлагаю голосовать:
|
|
|
|
16.02.2017 12:14:10
|
|||||||||||||||
|
|
16.02.2017 12:19:26
бляха муха спец нашелся... который не может разобраться как блин в js данные передаются!!!
ПИСЕЦ! я кончил! |
|
|
|
16.02.2017 12:20:04
в компонент я не только заглядывал но и кастомизировал шаблон - вставляя в него доп.данные и функции!
|
|
|
|
16.02.2017 12:23:48
Но сначала всё таки почитай что-нибудь по основам программирования. |
|||
|
|
16.02.2017 13:57:00
Артём Дубин, А вам лень что ли разобраться в компоненте ? Там нет ничего сверхестественного, при желании можно все понят.
Хотя вы наверно как мой коллега, я буду ждать официальной документации, а работать с новым не буду ибо там все сложна, да ? |
|
|
|
16.02.2017 16:16:45
В компоненте разбираться да, лень, но приходиться. При желании можно всё понять, но вы что предлагаете, разбирать скрипт в 8000 строк размером после каждого выхода обновления, внесения туда нового функционала, изменения структуры? Вот я и пришёл к выводу что описание этого компонента очень помогло бы мне как модифицировать существующий шаблон, так и написать свой если потребуется. Я не знаю какой там у вас коллега, но мне ничто не мешает как решать возникающие проблемы - так и предлагать разработчикам упростить нам работу, не вижу ничего в этом зазорного. И это что, принцип такой, во всём самому разбираться и ни в коем случае не предлагать разработчикам упростить себе работу? |
|||
|
|
16.02.2017 16:26:40
|
|||||
|
|
16.02.2017 16:37:41
Поможет это очень сильно, особенно при разработке своего шаблона с нуля. Ну и разобрать как работает та или другая функция с помощью такой документации гораздо проще. Ну а такому высокомерному гению как ты - то вообще 5 минут делов. |
|||
|
|
16.02.2017 16:38:09
Александр Кулеша, А что это плохо, если опишут что делает каждая функция? Или каждый раз код разбирать? Зачем тогда вообще документация нужна?
Если я долго не отвечаю |
|
|
|
16.02.2017 16:44:57
js штатного шаблона всё через аякс дёргает из компонента, достаточно описать структуру всех запросов и формат ответов (а главное поддерживать это в актуальном состоянии, чтоб не лезть в это скрипт и не расшифровывать по новой чего там изменилось). |
|||
|
|
17.02.2017 10:04:42
|
||||
|
|
|||