D365: passing through public method by means of Pre- and Post-event handlers

[mazzy]

Цитата:

Сообщение от wojzeh

можешь вкратце набросать бриллиантово-чистый пример?
именно в этом и задача. ещё раз: как бы ты решил эту задачу?

Я не знаю как правильно решить поставленную задачу в поставленных условиях.
Я бы изо всех сил постарался изменить формулировку задачи. Я бы постарался донести последствия силового решения. Если бы мои уговоры не сработали, то практическое решение было бы похоже на то, что приведено в блоге - стиль "сломать через колено".

Но мне чертовски не нравится что система вынуждает писать именно так.

Мне чертовски не нравится, что через несколько лет придется с последствиями решений, которые были сделаны в таком стиле.

А еще больше мне не нравится, систему сейчас делают такой совершенно конкретные люди. И они это делают точно не со зла.

[wojzeh]

Цитата:

Сообщение от mazzy

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

ок, формальное одобрение верховного жреца всё же получено.

как смотришь на то, чтоб убрать весь "эмоциональный шум" из этой ветки? так чтоб читатели могли выцепить суть, не отвлекаясь на "куда катится этот мир".

[mazzy]

Цитата:

Сообщение от wojzeh

ок, формальное одобрение верховного жреца всё же получено.

это не одобрение )

Цитата:

Сообщение от wojzeh

как смотришь на то, чтоб убрать весь "эмоциональный шум" из этой ветки? так чтоб читатели могли выцепить суть, не отвлекаясь на "куда катится этот мир".

удалять документы? )))))

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

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

[wojzeh]

Цитата:

Сообщение от mazzy

это не одобрение )


удалять документы? )))))

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

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

про несколько уровней убедил. почему-то вспомнился адъ.

я именно такой пост в оригинале и создал - с выжимкой.

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

[ax_mct]

Цитата:

Сообщение от wojzeh

я именно такой пост в оригинале и создал - с выжимкой.

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

pre()>Save
standard method()
post()>Restore

В принципе это самый что ни на есть workaround. Который великолепен если его воспринимать именно как workaround.

А есть какой-то способ избежать вызова "standard method()" или подменить его?
И интересно почему, если это в любом случае ад, не хотят давать возможность такого полного перекрытия? Ведь для этого не нужен именно overlay сверху, можно overlay и сбоку.

Как понимаю ce.CancelSuperCall() помогает избежать вызов двух форм и добавили это как фикс, а не как часть общего дизайна.

[wojzeh]

у них на выходе всё в порядке!

[belugin]

Цитата:

Сообщение от ax_mct

И интересно почему, если это в любом случае ад, не хотят давать возможность такого полного перекрытия? Ведь для этого не нужен именно overlay сверху, можно overlay и сбоку.

как я понимаю. Общая задача осуществить механизм безболезненных обновлений.

Предположим, у вас есть метод X класса Y у метода есть его публичный интерфейс:

• предусловия
• постусловия
• инварианты

И есть реализация (например он может изменить приватную переменную невидимую снаружи). Если расширения смогут отменять вызов какого угодно метода, то состояние объекта может быть испорчено. Так как ваше расширение не может учесть внутреннее состояние объекта будущих версий.

Например в версии 1 вы написали расширение отменяющее вызов метода x целиком и как-то сымитировали его работу без того, что нам надо.

И есть реализация (например он может изменить приватную переменную невидимую снаружи). Если расширения смогут отменять вызов какого угодно метода, то состояние объекта может быть испорчено. Так как ваше расширение не может учесть внутреннее состояние объекта будущих версий.

Например в версии 1 вы написали расширение отменяющее вызов метода x целиком и как-то сымитировали его работу через публичный интерфейс.

В версии 1 sp 1 внутрь добавили кеш, которое ваше расширение обновить не может (не только потому, что оно не может модифицировать приватные поля, но и потому, что оно написано для версии 1, про sp1 не знает) в результате остальные методы класса берут данные из кеша устаревшие.

Собственно, если сделать подмену произвольного метода, то это и будет практически оверлееринг, но без удобного способа смотреть изменения.

[ax_mct]

Цитата:

Сообщение от belugin

как я понимаю. Общая задача осуществить механизм безболезненных обновлений.
...
Собственно, если сделать подмену произвольного метода, то это и будет практически оверлееринг, но без удобного способа смотреть изменения.

Спасибо, задумка понятна. Сделать это безболезненным. Но разве что только для вендора и то недолго. Все равно надо проводить при каждом обновлении аудит изменений на их логическую уже совместимость.

Ничего страшного в подмене нет. Это даст больше управляемости и надежности. А проверять конфликты можно и компилятором.

В этой теме рассматривается паттерн обхода который в данном конкретном случае безопасен, но при отсутствии возможности подмены всего метода целиком, это превратится в рутинный подход который иначе как суицидным не назовешь.

Kashperuk пишет что в Platform Update 11 что-то такое появится. Радостно наблюдать как пишется новый продукт.
https://docs.microsoft.com/en-us/dyn...tform-releases

[EVGL]

Цитата:

Сообщение от belugin

И есть реализация (например он может изменить приватную переменную невидимую снаружи). Если расширения смогут отменять вызов какого угодно метода, то состояние объекта может быть испорчено. Так как ваше расширение не может учесть внутреннее состояние объекта будущих версий.

Это все только слова и теоретические рассуждения. На практике все происходит с точностью до наоборот, и я могу это доказать на цифрах. При переходе с 7.1 на 7.2 наше приложение согласно отчету анализа обновления было затронуто 119 (прописью: сто девятнадцать) уничтоженными полями или таблицами, и это только data dictionary. Весь код, который это использовал - расширения, перекрытия, классы с бизнес-логикой - может идти лесом. Т.е. мастера по redesign / reengineering в Microsoft плевали на доработки и партнерские решения. Они ломали и будут ломать, с корнем удалять, менять внутреннюю логику. При этом самое худшее, что может случиться, это формально компилируемый код расширений, который просто перестал вызываться или работать из-за изменения порядка исполнения объектов.

[kashperuk]

Цитата:

Сообщение от ax_mct

А есть какой-то способ избежать вызова "standard method()" или подменить его?

Ждите Platform Update 11 который скоро появится

[wojzeh]

Цитата:

Сообщение от kashperuk

Ждите Platform Update 11 который скоро появится

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

[skuull]

Цитата:

Сообщение от ax_mct

А есть какой-то способ избежать вызова "standard method()" или подменить его?

Есть :

[ExtensionOf(classStr(Class1))]
final public class Class1_Extension
{
    public void run()
    {
        try
        {
            if (true)
            {
                throw Exception::Error;
            }
            next run();
        }
        catch (Exception::Error)
        {
            info('Done!');
        }
    }
}

Такое же эксплуатирование деталей (кривых) реализации как и в этом блоге. В любой момент починят (или поменяют реализацию XppPrePostArgs) и все развалиться к чертям, но кого это останавливает ?

Я так и не понял из ответов выше, зачем все это если есть CoC или просто автор еще про нее не узнал?

[ax_mct]

Цитата:

Сообщение от skuull

Я так и не понял из ответов выше, зачем все это если есть CoC или просто автор еще про нее не узнал?

CoC - Clash of Clans?

Как понимаю в CoC нельзя не вызывать next. И соответственно мы не можем вырезать или заменить то что нам не нужно. Только в очередной раз облизать. И автор темы решит свою проблему точно так же опасно с CoC как и Pre/Post, только вместо двух методов будет один. Сам же по себе такой способ как паттерн решения не должен быть промышленным. Рабочий но потенциально опасный workaround. После которого инженер должен пойти и хорошо напиться.

Возможно именно обязательность вызова next изменят в PU 11. О чем то же Kashperuk намекает.

P.S. вьехал в код - мы обходим вызов NEXT прыгая исключением. Неплохо. Это реально используется?
А можно создать свой собственный тип исключения, Exception::TODO? А что мне нравится, я правда столько не выпью, но в аду как в аду

Но наш кокретный гений Michael Fruergaard Pontoppidan по ходу математик, а не кибернетик.
Заменять метод - это фу, потому что тогда кто-то покажется нелепым.

Цитата:

Overlayering gives you the ability to replace any method. You take a copy of the original method and can edit it as you please. There is some tooling on top that gives a better experience, but at the end of the day customizations done this way are intrusive, and cannot be upgraded automatically. (For example, when the original code is changed, those changes must be merged in.)
If CoC allowed skipping the execution of standard code, you could take a copy of the standard code, edit it in any way you want, place it in a wrapper method and voila – you had overlayering in disguise. If we allowed this, we would be back to square one. CoC would have the exact same replacing semantics and problems as overlayering – just without the tooling.

https://blogs.msdn.microsoft.com/mfp...in-of-command/

[wojzeh]

Цитата:

Сообщение от skuull

В любой момент починят (или поменяют реализацию XppPrePostArgs) и все развалиться к чертям, но кого это останавливает ?

что значит "поменяют"? уберут метод добавления нового параметра? уберут метод доступа к объекту? как оно будет компилироваться в таком случае? это же не какие-то там недокументированные возможности, а как раз для того и предназначенные.

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

Цитата:

Сообщение от skuull

Я так и не понял из ответов выше, зачем все это если есть CoC или просто автор еще про нее не узнал?

я не узнал, сорян. можешь дать толковую ссылку? спасибо

[wojzeh]

Цитата:

Сообщение от mazzy

Но мне чертовски не нравится что система вынуждает писать именно так.

Мне чертовски не нравится, что через несколько лет придется с последствиями решений, которые были сделаны в таком стиле.

А еще больше мне не нравится, систему сейчас делают такой совершенно конкретные люди. И они это делают точно не со зла.

Aye, Sir!

[mazzy]

Цитата:

Сообщение от wojzeh

Aye, Sir!

все - не хорошее слово.
как только появляется слово все - жди логических ошибок )))

http://coub.com/view/vqeal