Hi,
As out of the box the RegionViewRegistry provided by Prism is used for the entire application and it does not allow to remove a previous registration. Hence in order to acquire the functionality you are describing you will need to take advantage of the extension points provided by Prism to implement you own custom logic.
A possible approach for example could be to use the implementation provided in the following blog post:
This approach basically allows to define a view registration only for an specific RegionManager. If you are using a scoped RegionManager for each window then you could register the view with said region manager each time a window is shown. As each window will have its own RegionManager, you should not experience issues with the previous registrations.
However, this approach also creates other problems. First, the previous delegates will be still stored in the RegionViewRegistry, which could cause memory leaks. Second, if the RegionManagers of two windows are identical, they might return the same hash code, making this approach pointless for this scenario.
Another approach could be to use to create a scoped RegionViewRegistry for each window. Basically what defines the "scope" where the registration of the views will have effect are the AutoPopulateRegionBehaviors that are subscribed to the RegionViewRegistry. By default, those behaviors subscribe to the global RegionViewRegistry, but I believe they could be created manually passing them the scoped RegionViewRegistry they should subscribe to in its constructor. Then you just need to replace the behavior in the region using the same behavior key. The problem with this approach is that you will need to access the Region itself to change the AutoPopulateRegionBehavior and if you have access to the region it would be easier to simply inject the view in it manually.
As it can be seen, trying to implement this functionality using the RegionViewRegistry is not a trivial task.
In my opinion, the easiest approach is to inject the view directly instead of using the RegionViewRegistry. The functionality that the registry provides can be simply obtained by first checking if a Region exist. If not, then you can subscribe to the CollectionsChanged event of the Regions collection in the scoped RegionManager. When a Region is added to the RegionManager, the event will be fired allowing you to add the corresponding views to the Region.
I hope this helps,
Damian Cherubini
http://blogs.southworks.net/dcherubini
As out of the box the RegionViewRegistry provided by Prism is used for the entire application and it does not allow to remove a previous registration. Hence in order to acquire the functionality you are describing you will need to take advantage of the extension points provided by Prism to implement you own custom logic.
A possible approach for example could be to use the implementation provided in the following blog post:
This approach basically allows to define a view registration only for an specific RegionManager. If you are using a scoped RegionManager for each window then you could register the view with said region manager each time a window is shown. As each window will have its own RegionManager, you should not experience issues with the previous registrations.
However, this approach also creates other problems. First, the previous delegates will be still stored in the RegionViewRegistry, which could cause memory leaks. Second, if the RegionManagers of two windows are identical, they might return the same hash code, making this approach pointless for this scenario.
Another approach could be to use to create a scoped RegionViewRegistry for each window. Basically what defines the "scope" where the registration of the views will have effect are the AutoPopulateRegionBehaviors that are subscribed to the RegionViewRegistry. By default, those behaviors subscribe to the global RegionViewRegistry, but I believe they could be created manually passing them the scoped RegionViewRegistry they should subscribe to in its constructor. Then you just need to replace the behavior in the region using the same behavior key. The problem with this approach is that you will need to access the Region itself to change the AutoPopulateRegionBehavior and if you have access to the region it would be easier to simply inject the view in it manually.
As it can be seen, trying to implement this functionality using the RegionViewRegistry is not a trivial task.
In my opinion, the easiest approach is to inject the view directly instead of using the RegionViewRegistry. The functionality that the registry provides can be simply obtained by first checking if a Region exist. If not, then you can subscribe to the CollectionsChanged event of the Regions collection in the scoped RegionManager. When a Region is added to the RegionManager, the event will be fired allowing you to add the corresponding views to the Region.
I hope this helps,
Damian Cherubini
http://blogs.southworks.net/dcherubini