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

[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/

[skuull]

Цитата:

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

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

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

[skuull]

Цитата:

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

А можно создать свой собственный тип исключения, Exception::TODO? А что мне нравится, я правда столько не выпью, но в аду как в аду

Вы можете ловить c sharp исключения в 7ке, значит должны мочь их кидать, создайте свой тип и попробуйте

[wojzeh]

Цитата:

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

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

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

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

Цитата:

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

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

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

[kashperuk]

Цитата:

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

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

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

[wojzeh]

спасибо за ссылки

[skuull]

Цитата:

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

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

Ну такие ребята как Peter Villadsen конкретно про этот злобный хак говорят:

Цитата:

Will the approach work? Probably: The arguments are collected in an X++ struct (i.e. name / value pairs). Will we guarantee that it will work forever? No.

Там как раз в соседней ветки возмущаются по поводу удаленных полей между релизами, так что могут поломать запросто, как поломали pack\unpack в PU10, а казалось бы фундаментальная фича. Edited: вот уже и в эту ветку притащили

Идея то не нова и была полезна до CoC, а щас никчему.

Цитата:

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

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

Помимо видео от Вани\mfp, https://docs.microsoft.com/en-us/dyn...d-wrapping-coc

[wojzeh]

Цитата:

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

Идея то не нова

so nothing stops us!! (<strike>Russian</strike> great minds think alike!

заодно узнал про статические переменные класса...

[wojzeh]

Цитата:

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

https://docs.microsoft.com/en-us/dyn...d-wrapping-coc

Цитата:

When the call to the next DoSomething method occurs, the system randomly picks another method in the CoC

а чем это принципиально отличается от связки пре-пост?

я вот набросал рапчик:

[Wrappable(true)]
[HookableAttribute(false)]
str Yahooyeyou()
{
  return "For the features that are described in this topic, the Microsoft Visual Studio X++ editor doesn't yet offer complete support for cross-references and Microsoft IntelliSense."
}

[skuull]

Цитата:

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

заодно узнал про статические переменные класса...

Видимо правду говорят, что в Канаде сплошь лес да медведи

Цитата:

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

а чем это принципиально отличается от связки пре-пост?

1.Оборачиваються protected методы.
2.Доступ к protected полям класса.
3.Ненадо мучать пре-пост аргументы.
4.Можно добавлять состояние (фишка не СоС но там может пригодиться)
5.Удобный синтаксис
6.Извращенцы могут скипнуть next.

[wojzeh]

Цитата:

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

Видимо правду говорят, что в Канаде сплошь лес да медведи
...
2.Доступ к protected полям класса.
...
6.Извращенцы могут скипнуть next.

я сам удивлён, как сдал экзамен по новой версии...

2. доступ к полям класса - есть примерчик?
6. скипнуть некст - и чо будет? по-моему, это самое интересное.

технически такая обёртка делается наследником класса с перекрытием метода и вызовом его супера, или есть какой-то другой подход?

[skuull]

Цитата:

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

6. скипнуть некст - и чо будет? по-моему, это самое интересное.

технически такая обёртка делается наследником класса с перекрытием метода и вызовом его супера, или есть какой-то другой подход?

Наследник без супера это хороший вариант, плохой в этой же теме на 2 странице D365: passing through public method by means of Pre- and Post-event handlers

Цитата:

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

2. доступ к полям класса - есть примерчик?

Ну есть у вас класс

class BusinessLogic1
{
 protected int a;
}

и вы можете делать так

[ExtensionOf(ClassStr(BusinessLogic1))]
final class BusinessLogic1_Extension
{
    public int getA()
    {
        return a;
    }
}

Очень полезно когда работаешь с классами\формами где переменные protected и доступ через Pre\Post к ним нет.

[ax_mct]

Цитата:

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

а чем это принципиально отличается от связки пре-пост?

Способом доступа к переменным. Так мы берем и хакаем через Args, а так мы имеем право сделать обертку и использовать члены напрямую.

Но все равно данный паттерн "обход базового метода с временным присвоением внутреннего условия" он заслуживает патента.

У меня сейчас на четвертые сутки запуска на клиенте AX2012 самоудалилось немало заказов на живом приложении. Вылечилось одной строчкой кода для обхода стандартного удаления заголовка интер. закупки при удалении оригинального заказа. Как с таким справится ь в AX7 мне даже страшно ум приложить. По данному паттерну мне в СоС надо

RecId recId = _salesTable.RecId; 
_salesTable.RecId = 0

next purchTableDelete(_salesTable)

_salesTable.RecId = recId;

Вот она какая красота расширений!
А overlayering это слишком тупо, да.

void purchTableDelete(SalesTable _salesTable)
{
    InterCompanyPurchSalesReference interCompanyPurchSalesReference;
    PurchTable                      purchTable;

    if(!_salesTable)
    {
        return;
    }

    if (_salesTable.SkipUpdate == InterCompanySkipUpdate::Internal
    ||  _salesTable.SkipUpdate == InterCompanySkipUpdate::Both
    || !this.canCreatePurchOrder())
    {
        return;
    }

    while select PurchId from interCompanyPurchSalesReference
         index hint SalesPurchIdx
         where interCompanyPurchSalesReference.SalesId == _salesTable.SalesId
    {
        select forupdate purchTable
               index hint PurchIdx
               where purchTable.PurchId == interCompanyPurchSalesReference.PurchId
               &&    purchTable.InterCompanyOrder;
        if (purchTable.isInterCompanyOrder()
        && purchTable.SalesOSInterOrigin != SalesOSInterOrigin::Sourcing) // добавлено
        {
            purchTable.SkipUpdate = InterCompanySkipUpdate::Internal;
            purchTable.delete();
        }
    }
}

--------------------------------
Хороший рябчик, да