Tags

, ,

As part of its set of guidance, Prism provides an exemplar implementation to follow in case you ever need to roll up a custom behavior to be attached to your regions. Situations in which such scenario may occur can range from monitoring regions having certain behavior and adapting them accordingly or just adapt/add a custom behavior to all regions. This post concerns the latter, and for easy blending unto PRISM pipeline, we hook the behavior during the boot strapping process. In a later post I’ll cover how I added a new behavior dynamically through a region adapter provided as part of a module.

To start off, I based the design of my behavior on StockTraderRI AutoPopulateExportedViewsBehavior available from the desktop infrastructure branch. Please note the design is equally applicable to Silverlight; that’s the whole beauty of PRISM: Targeting multiple platforms at once.

By default when your Bootstrapper is instantiated and its run method called from your Silverlight App entry point (Application_Started method), the base MEFBootStrapper run method is called unless you also override it. It is within that process that ConfigureDefaultRegionBehaviors gets called and it uses the provided global IRegionBehaviorFactory implementation to house the core default behaviors mapped to all regions. So inside the ConfigureDefaultRegionBehaviors override of my BootStrapper I have the following code:

In the above Code block, our custom behavior is AutoPopulateExportedViewsBehavior and it has mainly three methods at its core:

OnAttach : called when the behavior is newly/initially attached to a region.

OnImportSatisfied: when an objects that meets the requirement of the contract to expose itself as a view is exported and added to our container of Lazy<object, IViewRegionRegistration>[] RegisteredViews. For an object to be qualified as a view, it must be tag with an export attribute that implement IViewRegionRegistration

AddRegisteredViews: Called by the above methods to load views into the region when appropriate. This is where most of your logic pertaining to views activation would occur. As a pointer anytime you activate a view inside a SingleActiveRegion the previously activated view gets deactivated

The importing constructor takes an IRegionViewRegistry and passes it to its base. The importing constructor also takes additional infrastructure component such as RegionManager required in my particular scenario.

Conclusion

It is obviously easy to use one’s own custom logic deciding when and how views get registered and activated initially, but also which objects qualify as views

Advertisements