Различные виды кризисов задержали продолжение этой серии. Считаю, что надо ускориться и покончить с ней.
Сегодня опишу механизм публикации настроек плагинов. Построен он на инфраструктуре, которую я описывал ранее. Рекомендую для начала ознакомиться с ней, для того чтобы понимать о чем будет идти речь. Вкратце, решение состоит из нескольких интерфейсов, определяющих функциональность, пары классов для хранения настроек (примитивных типов данных, строк и т.п.) и конфигурационного диалога, который управляет отображением всего этого добра. Для плагинов потребовалась небольшая адаптация в виду того, что загружаются они в изолированые sandbox'ы.
Итак, может так статься, что вам понадобится управлять какими-то параметрами плагина. Есть несколько способов это сделать: поместить в UI плагина какой-то элемент, например кнопку, которая будет запускать форму настроек; а можно делать это централизовано, в единой форме настроек хоста, что лично мне кажется более правильным.
Cоздавая плагины на основе MAF, мы имеем возможность хостить их в отдельных доменах приложения и даже в отдельных процессах, а значит, для того чтобы код хоста мог работать с настройками плагинов, их надо подготовить к передаче через эти границы. Так как настроечные интерфейсы представляют из себя совокупность предоставляемой функциональности, то, очевидно, передача по значению в данном случае не подходит, и наши настроечные объекты должны передаваться по ссылке. Эти требования форсировали разработку новых интерфейсов и классов.
Здесь IAddInTuned - интерфейс, который должны реализовывать классы настроек плагинов. Его дополнительная функция, помимо управления настройками, это передача через границу домена несереализуемого объекта изображения WPF, что реализуется в базовом классе AddInTuned при помощи кодирования изображения в массив байтов и последующего восстановления на стороне хоста.
Большинство свойств и функций, реализуемых этим классом интерфейсов, объявлены виртуальными, для того чтобы конкретные наследники класса могли их переопределить. Задачей представления данного объекта на стороне хоста занимается уже встречавшийся нам в одной из первых частей класс AddInTunedHostWrapper. Он не только восстанавливает изображения после передачи через границу домена, но и пользовательский интерфейс, предназначенный для представления и редактирования настроек.
Передается этот объект настроек и пользовательское представление, как вы наверное помните представлению объекта хоста на стороне плагина HostObject.
который затем по цепочке адаптеров передает эти объекты и в адаптере стороны хоста создает обертку AddInTunedHostWrapper для прозрачного представления настроек хосту.
AddInTunedHostWrapper делегирует все входящие вызовы внутреннему переданному TransparentProxy, который инициирует вызов методов объекта AddInTuned в домене плагина через remoting.
Вот так вкратце выглядит решение для передачи настроек плагинов на сторону хоста.
Ну и приведу пример кода, дабы было понятнее.
Сторона плагина.
Сам плагин.
Настройки плагина.
Представление настроек.
Результат.
Надеюсь я вас не разочаровал убогим примером.
- Part 1. Overview.
- Part 2. MAF addin UI - gadget. Object model.
- Part 3. WPF-interop and "airspace" notion - hosting gadgets in complex shape windows.
- Part 4. Publishing MAF addin settings.
- Part 5. Handling unhandled exceptions in isolated addin domains, gadget host.
- Part 6. Cross-AppDomain events propagation powered by Juval Lowy's WCF Pub-Sub framework.
