|
![]() |
#1 |
Участник
|
Спасибо. С этим разобрался, да и видел подобные статьи. Теперь другое не получается реализовать. Например в 2012 в стандартные методы типа insert я мог добавить аргумент insert(int _i = 0).
Как сделать подобное в 365? |
|
![]() |
#2 |
Участник
|
Никак. И так же вы сможете передать новый параметр из существующего кода - никак. Остаётся способ передачи переменных через глобальный кеш или статические поля, но это уже на грани с извращением. Вы лучше задачу опишите.
Последний раз редактировалось skuull; 24.01.2018 в 21:32. |
|
![]() |
#3 |
Banned
|
Цитата:
Virtual Field c "SaveContent" = No? Или завести поле .myParameters типа контейнер и грамотно класть и парсить через свой фрэйморк для этого. Я бы вообще такой контейнер добавил в .common ![]() А если серьезно то лучше забыть о таких задачах как "как правильно переопределить метод в таблице" в D365. Парадигма программирования изменилась. Только отсутствие связи или очень слабые связи, то есть или своя таблица или подписка на событие как отмашка. |
|
![]() |
#4 |
Участник
|
Я про это и говорил упоминая извращения. Непонятно что автор собираеться с этим параметром делать.
|
|
![]() |
#5 |
Administrator
|
Цитата:
Теперь у нас есть события. Этих событий мы можем наплодить великое множество, гораздо больше, чем 2 варианта. Более того, мы в коде можем управлять последовательностью вызова обработчиков этих событий. Соответственно, теперь каждая логика будет иметь свой обработчик события insert(). Тут есть 3 варианта развития. Можно как-то внутри себя договориться и использовать единый обработчик insert-а (один класс) и в нем реализовывать все 100500 вариантов логики. Пример в прошлых версиях - класс InventUpdate и его наследники InventUpd_*. В нашем случае через GlobalCache можно будет создать единый инстанс этого обработчика и следить за этим. Минус такого подхода в том, что должен быть единый и постоянный архитектор, который за этим будет следить. Не все компании считают нужным содержать такого человека. Есть второй вариант, делать независимые обработчики и потом разгребать их конфликты в части порядка их вызова. Тут будет работать правило - кто последний, тому и сложнее. Ну и последний вариант - стараться отучать себя от программирования на insert/update/delete. Всегда можно найти способ этого не делать. Просто очень часто туда вставляют код, т.к. тяжело найти все те места в системе, которые могут вылезти уже после приема разработки. Но такой подход - лишь отсрочка этой проблемы, т.к. постепенно на insert / update / delete переползет вся бизнес-логика модификаций. Еще маленькое замечание - в целом неважно как "обрастет" код и насколько будет сложно его поддерживать. Конечно есть еще компании, у которых работает AX 3.0, но в большинстве своем жизненный цикл конкретной версии системы не настолько большой (лет 10), поэтому рано или поздно ее все равно будут менять и по сути перевнедрять, т.к. много воды уже утечет с момента первого внедрения. Причем что примечательно, что как раз-таки те компании, которые до сих пор сидят на 3.0 вероятнее всего не имеют и давно уже не имели того единого архитектора, который бы мог все контролировать. Так что плюс-минус неважно насколько "плохим" или "хорошим" со стороны окажется Ваше решение по выбору обходного пути. Соответственно прямой ответ на вопрос - никак, но есть разные обходные пути, которые могут решить исходную задачу иным способом.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 25.01.2018 в 00:31. |
|
|
|