Radical.Windows.Presentationhas a lot of runtime conventions mainly related to two different areas:
IConventionsHandlerinterface, and allows to take full control of the following Radical behaviors:
ViewReleaseHandleris called each time a
Viewshould be released, this handler is responsible to release the
Viewand its associated
ViewModelif any. This handler also unsubscribe, if allowed by the
ViewModelfrom all the subscriptions registered with the
Viewshould be released when required.
ViewModelsubscriptions should be unsubscribed at release time.
Viewis released, the default behavior is to destroy region managers only if the
Viewis not a singleton view.
ViewModelavailable in the
Viewresources. ShouldExposeViewModelAsStaticResource and ExposeViewModelAsStaticResource control if a
ViewModelis exposed as a resource (
falseby default) and how it is exposed. The default behavior, when this feature is active, is to register the
ViewModelin the resources using its
Typename as the resource key.
ViewDataContextSearchBehaviorhas been introduced to overcome an issue encountered due to the way dependency property value inheritance works. When using nested views, for example because one child view is loaded as a content injected into a region, if the nested view does not have a DataContext property (e.g. is a view without a ViewModel) its DataContext property value is inherited from the first element in the logical tree that has a DataContext assigned. This default WPF behavior was causing some subtle bugs in the way the Radical MVVM logic was working. The ViewDataContextSearchBehavior has been introduced to determine the way the MVVM engine will look for the ViewModel on a View, the default behavior, that can be controlled via the
DefaultViewDataContextSearchBehaviorproperty, is to look only on the View DataContext property ignoring each inherited value.
Viewshould notify that is loaded broadcasting a
ViewLoadedmessage. A view notifies that has been loaded in 2 cases:
Radical.Windows.PresentationMVVM and UI Composition toolkit needs to know the runtime View – ViewModel relations in order to know that given a ViewModel instance the corresponding View instance is certainly a specific instance.
ViewResolveronce has resolved both the required instances calls the
AttachViewToViewModelconvention in order to store the view reference in the view model instance (the view model is already stored in view instance using the
AbstractViewModeltype implements the
IViewModelinterface that has a
Viewproperty internally used for this tasks. If the user does not like this behavior or cannot inherit from the
AbstractViewModeltype, nor implement the
IViewModelinterface, can replace this convention in order to store somewhere else the required relation (e.g. a statically defined dictionary).
GetViewOfViewModelconvention that is required to retrieve the stored relation.
IsHostingViewconvention is internally used by the
Regionbase class to determine if a given visual element can be considered a View.
System.Windows.Interactivity.Behavior<T>) whenever a view is resolved by the ViewResolver. By default the built-in
ViewResolverattaches the following behaviors to each view: