Цитата |
---|
Евгений Жуков написал: Чтобы автоматически внутри обработчика получить контекст вызова |
С BX.delegate и BX.proxy дебажить (а я бы даже сказал реверс инжинерить - документации не хватает) битрикс то ещё удовольствие
30.03.2020 00:44:19
С BX.delegate и BX.proxy дебажить (а я бы даже сказал реверс инжинерить - документации не хватает) битрикс то ещё удовольствие |
|||
|
|
30.03.2020 10:16:26
Я бы предложил такой вариант: добавить к ссылке какой-то свой уникальный get-параметр, а в обработчике события его обрабатывать и вызывать метод
|
|||||||||||
|
|
30.03.2020 15:01:54
В оф. инструкции о BX.proxy и BX.delegate сказано:
При создании объекта (как правило при загрузке страницы) в объекте инициализируются ОООГРОМНАЯ толпа переменных, методов и свойств объекта, которые могут динамически меняться в результате работы скриптов. Так вот самый простой способ получить к ним доступ в объекте через ключевое слово this.: this.СВОЙСТВО, this.МЕТОД или this.ФУНКЦИЯ(). Все просто пока мы не начнем делать вложенность в объекте. Например, у нас есть объект, с набором методов и свойств, которые имеют свои свойства и методы. Так вот this, будет ссылаться на объект, который стоит перед точкой, и таким образом получить данные которые имеет объект при инициализации недоступны. А теперь живой кейс: Объект: BX.CrmProductEditor (bitrix/components/bitrix/crm.product_row.list/templates/.default/script.map.js)
а очень хочется. Вот тогда помогает делегирование ( onsuccess: BX.delegate(this._w4aOnSaveProductsRequestSuccess, this)) И мы делегируем методу _w4aOnSaveProductsRequestSuccess обработку результата, с передачей ему полученных результатов. ============================= ЗЫ Не знаю правильно ли я объяснил, тут наверное про this лучше написано |
|||||||
|
|
30.03.2020 15:11:31
Можете привести конкретный кейс, где это может быть лучше? |
|||
|
|
30.03.2020 18:03:55
Или я просто не понял что делаешь) BX.CrmProductEditor я получаю так
или если метод короткий то прямо так
Я понимаю какие проблемы решают BX.delegate и BX.proxy, но эти проблемы уже не актуальны несколько лет. Загляни сам в "новое" ядро bitrix/js/main/core/src/lib никаких делегирований и прокси и правильно |
|||||||||||
|
|
31.03.2020 09:24:44
вот 1-на из них: расширить таблицу товаров: было добавлено 11 доп. полей, такие как:
В итоге из такого массива (штатный):
Так вот все эти доп. поля участвуют в пересчете значений других полей (в том числе и штатных) в процесе ввода значений поля. Опять же этот функционал сидит в BX.CrmProductEditor Задача усложнилась тем, что в других сущностях: Лид, Предложение должен был остаться штатный функционал Поэтому, ни чего другого, как перенести штатный компонент: bitrix:crm.product_row.list в свое пространство имен:w4a.bitrix:crm.product_row.list.calc и там его кастомизировать, я не придумал. Если есть менее затратные способы кастомизации, прошу поделиться. PSСорри за офтоп, но эти доп. поля как раз и выносятся в последствии в генератор документов. |
|||||||||
|
|
31.03.2020 10:41:02
пишу ВОЗМОЖНО, потому что,
Это искл. мое мнение. |
|||||||
|
|
01.04.2020 10:52:50
Не придумал ничего лучше, чем на vue написать собственный "компонент" работы с продуктами сделки. Мне показалось проще, чем переделывать нативный |
|||
|
|
01.04.2020 12:29:15
чтобы весь текущий (штатный функционал) остался!!! Хотя, я уверен, что большей частью из функционала он не будет пользоваться, но Хозяин-барин. По идее, да можно было бы свой компонент написать, но пришлось бы в него переносить весь (штатный функционал).
|
|||||
|
|
01.04.2020 12:36:12
И по факту свой компонент управлял штатным. К примеру, добавил в свой компонент товар - он добавился и в штатном, поменял количество - в штатном всё пересчиталось. Опять же так показалось проще в плане сохранения товаров. Не пришлось его писать - штатный это итак умеет)) |
||||
|
|
|||