Views hierarchy: Specializing hierarchy through interfaces

Views hierarchy: Specializing hierarchy through interfaces

April 03, 2009 0 Comments

The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.

[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:
public class BlogsListView : ViewModeControl<BlogsView> 
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.

public class ContentItemEdit<THost> : ViewModeControl<THost> where THost : Control, IGenericContentHost 
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.
public class NewsItemEdit : ContentItemEdit<NewsItemsView> 
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.

/// <summary> 
/// Defines the members that each host in Generic Content module needs 
/// to implement 
/// </summary> 
public interface IGenericContentHost 
        /// <summary> 
        /// Content Manager used by the control 
        /// </summary> 
        ContentManager Manager { get; } 
        /// <summary> 
        /// Gets the mode key for the host control 
        /// </summary> 
        string ViewModeKey { get; } 
        /// <summary> 
        /// Gets parameter key for the host control 
        /// </summary> 
        string ParameterKey { get;  } 
        /// <summary> 
        /// Gets the type of the view mode. 
        /// </summary> 
        /// <value>The type of the view mode.</value> 
        Type ViewModeType { get; } 
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.


The Progress Team

View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Comments are disabled in preview mode.
Latest Stories in
Your Inbox
More From Progress
5 Questions Automakers Should Ask to Improve Asset Uptime
Download Whitepaper
2018 Gartner Magic Quadrant Web Content Management (WCM)
Download Whitepaper
What Serverless Means for Enterprise Apps
Watch Webinar