Kashperuk Ivan: Development tutorial: Extensibility: Replaceable in Chain of Command methods

[kashperuk]

Цитата:

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

Интересно. Спасибо.
Я правильно понимаю что проверка конфликта решений ISV не на этапе компиляции, а как runtime error?

Ну, на этапе компиляции и раньше не было. Раньше два ISV могли подписаться на один и тот же метод, и вернуть результат unconditionally.
Это приводило к ситуации "Last man wins" (ну или first man, не суть)

С введением конструктора EventHandlerResult::singleResponse() теперь упадет ошибка, что, мол, попытка повторного вызова - это подобно тому, как это сделано в SysExtension framework

К сожалению, с Replaceable так не получается, то есть опять возвращаемся к First Man Wins - если безусловно не вызывать next() и ваш код вызовется первым, то у остальных не будет шанса, даже если по условиям ваш код ничего бы доп не сделал.


Да и вообще, сосуществование нескольких ISV решений - сложная тема. Если у кого-то есть идеи, как ее решить, я бы с удовольствием послушал.

[belugin]

Цитата:

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

Если у кого-то есть идеи, как ее решить, я бы с удовольствием послушал.

Так как это все равно синтаксический сахар для события, сделать дополнительные конструкции для этого:

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

[trud]

Цитата:

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

то exception.

Так и что будет делать пользователь с этим exception?

[belugin]

Цитата:

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

Так и что будет делать пользователь с этим exception?

Пользователь, это расплывчатое понятие. Конечный пользователь? Вообще как с любой другой ошибкой в софте - репортить программеру.

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

[trud]

Цитата:

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

Вообще как с любой другой ошибкой в софте - репортить программеру.

что за программер? ну т.е. я как конечный пользователь ставлю 2 сертифицированных решения из App store - у меня после этого перестает работать стандартный лукап по складам. т.е. по идее это ошибка MS(у разработчиков решений то все работает)
т.е. что должен суппорт MS делать с такой ошибкой?

[belugin]

Цитата:

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

по идее это ошибка MS(у разработчиков решений то все работает)

То что у разработчика расширения все работает, это не значит что ошибка не его. Например у него может быть локаль EN-US а у пользователя тайская, и он это не учел. Как и возможность наличия расширения.

Я не знаю, как решает такие вопросы саппорт, как и вопросы при любых 3rd party расширениях для всего чего угодно. Наверное должен быть кто-то, кто поддерживает весь комплект в целом. Так же как если у вас антифирус конфликтует с какой-нибудь утилитой вы обращаетесь к сисадмину.

[trud]

Цитата:

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

Как и возможность наличия расширения.

так а как разработчик должен это учесть? т.е. если вы предлагаете генерить исключение, надо наверное и предлагать механизм обработки этого исключения. если механизма обработки нет, зачем тогда его генерить?
вообще вот отличное описание о "будущем" NAV, странно что для АХ не сделают подобное.
russianerpexperience: Как вендор партнёра услышал, или будет ли Россия в облаке: новости о новейшей системе Dynamics 365 'Tenerife' с Directions EMEA 2017

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

[ax_mct]

Цитата:

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

Да и вообще, сосуществование нескольких ISV решений - сложная тема. Если у кого-то есть идеи, как ее решить, я бы с удовольствием послушал.

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

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

"Быстро, дешево, много" в части инсталляций - вполне работающий для прибыли для того у кого в руках контроль. Но рынка ISV рынка для D365FOE не будет, будет не больше одного ISV решения для бизнес-процессов на конкретном внедрении вот и все. И то если именно Microsоft будет формально или неформально гарантировать его совместимость.

То есть тесная совместная работа Microsоft с 1-5 ISV и все. Между собой все решат и так я полагаю.