Working with ContentView designer (part 4): Introduction :)

Working with ContentView designer (part 4): Introduction :)

October 30, 2008 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.

Yep, I did it again; started a series without an introduction. Romi pointed out to my ill practice, so here I am, writing an introduction in the fourth part of the series.

What are ContentView designers

ContentView designers were introduced in Sitefinity 3.2. Their purpose is to allow end users simple and quick way of editing a control without going to the property grid – in other words – they are the “basic” mode that you see when you edit ContentView based control. You can find built-in ContentView designers on following controls:

  • EventsView
  • BlogPosts
  • NewsView

ContentView designer is a control.

Take a look at the Figure 1 to see how does the EventsView ContentView designer looks like when you edit the EventsView control.

Figure 1: EventsView designer (both screens)

ContentView control designers are defined on the ContentView based control in a form of an attribute. Let’s take a look at how did we implement ContentView designer on the EventsView class.
[ControlDesignerAttribute("Telerik.Events.WebControls.Design.EventsViewDesigner, Telerik.Events")]  
public class EventsView : ContentView, ICategorizedControl  
   // ...  

We see that we are actually setting EventsViewDesigner class as a designer for this class, so what does that class do? Nothing special really – all it has to do is inherit from ContentViewDesignerBase and override the designer template property.

    /// <summary>  
    /// EventsView designer control  
    /// </summary>  
    public class EventsViewDesigner : ContentViewDesignerBase  
        public override string DesignerTemplatePath  
                if (ViewState["DesignerTemplatePath"] == null)  
                    return "~/Sitefinity/Admin/ControlTemplates/Events/Design/EventsViewControlDesigner.ascx";  
                return ViewState["DesignerTemplatePath"as string;  
                ViewState["DesignerTemplatePath"] = value;  

Well, things are starting to clear up now, aren’t they? ContentViewDesignerBase class is a very flexible class which works very well with the two controls that are the heart of the designers. Now, open the following file to examine those controls:


PresentationModes control

Let’s examine the PresentationModes control first:

              <sfDesign:PresentationModes ID="presentationModes" runat="server">  
                    <sfDesign:PresentationMode ID="listPageMode" runat="server"   
                                               ModeTitle="List &amp; page"   
                                               SelectedCssClass="selectedOption pageListMode" 
                                <asp:RadioButton ID="listPageRadio" runat="server" /> 
                                <p>A list of event titles, dates and summaries (optional). The full event info is opened in a separate page.</p> 
                    <sfDesign:PresentationMode ID="ExpandableList" runat="server"   
                                               ModeTitle="Expandable list"   
                                               SelectedCssClass="selectedOption expandableList" 
                                <asp:RadioButton ID="ExpandableListRadio" runat="server" /> 
                                <p>A list of event titles and dates. The full info is expanded in the same list when a title is clicked.</p> 
                    <sfDesign:PresentationMode ID="allInAListMode" runat="server"   
                                               ModeTitle="Expanded list"   
                                               SelectedCssClass="selectedOption allInListMode">  
                                <asp:RadioButton ID="allPostsInAListRadio" runat="server" /> 
                                <p>All events with their titles and the full info are in a common page.</p> 

As you can see the PresentationModes control (in Events designer) has Modes collection and three PresentationMode controls defined inside of this selection. Let’s take a brief look at the ModeTitle properties of these modes:

  • List & Page
  • Expandable list
  • Expanded list

Sounds familiar? Take a look at the Figure 2:

Figure 2: three presentation modes defined in the template

So, if we add one more PresentationMode control to the Modes collection of the PresentationMode control, there would actually be four modes available to user to choose from the Figure 2.

Let’s briefly examine the PresentationMode control and it’s properties.
  • ID – unique identifier of the mode control. Doesn’t really matter what you set it to as long as it is unique
  • ModeTitle – title of the mode that end user will see next to the radio button when opens the designer
  • ModeSettingsID – id of the mode settings control associated with this mode (we’ll come to this later)
  • MasterTemplatePath – path of the default template to be loaded when control is in the master mode (e.g. displays list of the events)
  • DetailTemplatePath – path of the default template to be loaded when control is in the detail mode (e.g. displays one single event)
  • CssClass – css class of the control
  • SelectedCssClass – css class of the control when selected (notice how List & Page mode looks differently than other modes in the Figure 2 – that’s done by the css)
  • Template – template of the control which lets you make the mode control look like it does. You can add description, images and so on

One of the major features of this approach is that you can now predefine the different modes for your end user and she can load it by simply selecting the mode. Looking through the file system to find the right templates is not necessary anymore.

PresentationModeSettings control

Remember the ModeSettingID property of the PresentationMode control I’ve described in the previous paragraph? That property associates particular mode with the specific PresentationModeSettings control. Now, I’ve talked quite a lot about this control in the previous posts of this series, so I won’t go into details here. The important thing to note, however, is that for each mode you can have different set of settings.


There are three ideas behind the ContentView designers that you can take advantage of:

  • Existing designers can be extended easily by simply modifiying the appropriate templates. Here is a list of currently implemented designers:
    o EventsView :
    o NewsView:
    o BlogPosts:
  • You can create a custom designer for your custom implementation of the ContentView control by simply inheriting from the ContentViewDesignerBase class and overriding the DesignerTemplatePath property. Then you need to implement the designer template which you can do by copying the markup of any of the built-in designers and then simply adjusting it to fit your needs (define the modes, settings and so on).
  • You can create a custom settings for the content view designers that can control the markup of the template in pretty much any way you think about it (stay tuned for the inline css setting!)

I hope that this has cleared the whole “designers situation” a bit more clear. In the next few posts I’ll wrap it up with demonstration of how to create custom setting and how to implement custom designer on the custom ContentView based control… and then we can move on – FilterExpression and ContentFilterBuilder class, perhaps.



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