Views hierarchy: Specializing hierarchy through interfaces

[This post is part of the developer's manual preview published on this blog. You can find temporary TOC here.]

 

This article is really more on C# generics, however we will examine some of the principles and see how can we apply them on the Views hierarchy. Namely, we know that every time we declare a View (be it ViewModeControl or ViewModeUserControl) we define the host of the control as a generic type of that class. An example of the View declaration looks like this: Now, in the code above we know that the Host (or parent) of the BlogsListView control is BlogsView. That means that with the this.Host property we will be able to access the members of the BlogsView from the BlogsListView.

 

However, there are cases when we don’t wish to hard code the host (or parent) of the View. Namely, as we will see in the articles on “Designing reusable Views” and “Host ambivalence”, sometimes it is opportune to develop Views which can be reused in different modules and in different places of the hierarchy. The key to this approach is not to hard code the host, but rather make it generic. Generic Content module, which is largely reused throughout Sitefinity, is a great example of such design. Let us take a look at the View declaration of one of the Generic Content module Views.

We can see that this declaration is much different, than the one for BlogsListView for example. The reason for this is the fact that we want ContentItemEdit View to be reusable by any module that wishes to do so. Now, if we take a look at the declaration of NewsItemEdit, we’ll see how easy it is to reuse this View. Now, that we’ve seen the two declarations, let us explain the idea behind this implementation. Namely, for the ContentItemEdit View we have set the host to be a generic argument - meaning that it can be any View we decide so (e.g. NewsItemsView in the News module or PostView in the Blogs module). While this would work perfectly fine, we would not be able to access any properties of the host in Generic Content, because no type has been defined. Therefore, we have decided to specialize the host of the ContentItemEditView’s host, by implementing the constraint where we state that whichever host ContentItemEdit View may have, this host must be a Control (or one of its derivations) and has to implement IGenericContentHost interface. Let us take a look at the IGenericContentHost interface and the members it mandates.

Having a look at this interface, we know that whichever host we decided to implement as a host of the ContentItemEdit View, it will surely implement following properties:

• ContentManager Manager
• string ViewModeKey
• string ParameterKey
• Type ViewModeType

This, finally, allows us to access these properties through the this.Host property from the ContentEditView, even though we don’t know what the host of the View will be. Therefore, we have created a host agnostic View, which is however, specialized for the Generic Content based modules.