mfp: Replaceable methods

[Blog bot]

Источник: https://blogs.msdn.microsoft.com/mfp...eable-methods/
==============
Chain of command enables wrapping of methods – but you must call next. This ensure the "chain" is not broken, and everyone wrapping the method will indeed be called. However, sometimes it makes sense to break the chain. Here are some examples where this could be useful: In lookup methods. The base implementation will open...

==============
Источник: https://blogs.msdn.microsoft.com/mfp...eable-methods/

[ax_mct]

Эх Ваня, Ваня...

Цитата:

Chain of command enables wrapping of methods – but you must call next. This ensure the "chain" is not broken, and everyone wrapping the method will indeed be called.

However, sometimes it makes sense to break the chain. Here are some examples where this could be useful:

In lookup methods. The base implementation will open a lookup dialog, anyone wrapping will (likely) also open a dialog. Yet the user only expects one lookup.

In methods with complex SQL operations. As of now; there are select statements (including delete_from, update_recordset, insert_recordset) we cannot make extensible. One way to work around the limitation is to move the statement to a dedicated method, and make the method replaceable.

In conversion methods. Here you can conditionally call next, to skip the base conversion, if your logic can handle the conversion.

In Platform Update 11 – we can now decorate methods with the [Replaceable] attribute. This will relax the compiler, so it doesn't look for the next keyword. Logically, this means that when wrapping a Replaceable method, there is no guarantee that your logic will fire. Someone else might be replacing the method, and breaking the chain.

The author of the code is still in control of which methods are replaceable.

My dear "partner in crime" Vanya Kashperuk has written a great post about the new capability here: http://kashperuk.blogspot.dk/2017/10...ibility_7.html

Обратите внимание на рассматриваемые примеры. Как далек он (изобретатель то есть) от клиента.

Сижу я значит на клиенте пол-года-год и все это время лукапы отгружаю. Паллетами.

[trud]

ну т.е. по сути они изобрели заново слои. со всеми теми же проблемами, но без вообще хоть какого-то тулинга разрешения конфликтов и сравнения, без поддержки существования нескольких версий(в CoC методы вызываются рандомно, т.е. если вы один и тот же метод замените в USR и ISV никто не гарантирует что вызовется USR).
главное конечно чтоб не получилось как с windows phone

Цитата:

«Мы очень старались стимулировать разработчиков. Платили деньги… писали для них приложения…

[belugin]

Цитата:

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

ну т.е. по сути они изобрели заново слои.

В слоях мы можем омерлеерить любой метод, а здесь - только такой как позволено.

По идее к этому должно прилагаться описание (например в XML документации), на что надеется вызывающий код (то есть контракт, который должны соблюдать расширения) и способ разрешения конфликтов между расширениями (вот
это нетривиально. Например не вызывать super можно только если есть уверенность что исходные данные сгенерированы расширением и больше никем).

Будут ли так делать или просто проставят атрибут в методах по требованию - посмотрим.

[trud]

Цитата:

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

В слоях мы можем омерлеерить любой метод, а здесь - только такой как позволено.

По идее к этому должно прилагаться описание (например в XML документации), на что надеется вызывающий код

Не понял идею с документацией. ну т.е. если смотреть его примеры - типичная задача - добавить в insert_recordset доп. поле.

[belugin]

Цитата:

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

Не понял идею с документацией. ну т.е. если смотреть его примеры - типичная задача - добавить в insert_recordset доп. поле.

Например в документации написать какой-нибудь признак, по которым разводить экстеншены с этими дополнительными полями (например генерация проводок для какого-то нового своего модуля). Либо в документации разрешить перекрывать только клиентам (которым не надо ни с кем сливаться).

[kashperuk]

Цитата:

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

В слоях мы можем омерлеерить любой метод, а здесь - только такой как позволено.

По идее к этому должно прилагаться описание (например в XML документации), на что надеется вызывающий код (то есть контракт, который должны соблюдать расширения) и способ разрешения конфликтов между расширениями (вот
это нетривиально. Например не вызывать super можно только если есть уверенность что исходные данные сгенерированы расширением и больше никем).

Будут ли так делать или просто проставят атрибут в методах по требованию - посмотрим.

Можешь привести пример, как ты видишь текст такой вот секции?
Отличался ли бы этот текст от метода к методу?

[belugin]

Цитата:

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

Можешь привести пример, как ты видишь текст такой вот секции?

Дупустим, у нас есть корреспонденция проводок реализованная на таких методах а не событиях.

"Расширение должно вызывать метод, кроме того, случая, когда в параметрах ГК установлено значения признака SummarizationAlgorithm равного значению, которое добавлено компанией-автором расширения.

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

Но на самом деле более очевидным было бы ввдедения интерфейса SummarizationAlgorithm и вызов его методов.

Цитата:

Отличался ли бы этот текст от метода к методу?

Да, потому, что нельзя придумать такой универсальный признак, по которому перекрывающие расширения гарантированно не пересекались.