Creating a new template for a built-in content list view

One of the main features of the Xmas preview edition of Sense/Net 6.0 Beta 5 is the Content List View framework. A Content List View is basically an ASP.NET User Control that can be used to display Content items in various fashions. We have created the framework to allow for several levels of customization. Deployers and builders have the option to create entirely new User Controls either with a compiled classbehind dll placed in the binary folder of the Sense/Net installation, or using solely declarative components, such as the newly introduced SenseNetDataSouce. However, existing, built-in views can also be altered, and several variants of a single built-in view can be created in the system.

The template engine

The framework of built-in Content List Views is comprised by two levels - a template level and an instance level. The instance level is the actual User Controls that are loaded and executed by the Webforms engine to display the Content List. Every View configured by users on a single List is represented by an instance containing the configuration-, and metadata of the view, and also the actual User Control code that is auto-generated from said metadata. What facilitates this auto-generation is the template level of the infrastructure.

In creating this template engine, we considered several options to use as the templating language. In the end we have decided for XSLT, considering its wide penetration in the web industry, and also its relative simplicity and power. The code that does the actual work in creating the instance View from the template resides in the class Portal.UI.ContentListViews.Handlers.ViewBase. This is the Content Handler for the Content type ContentListView, the type of View instances. Upon the Save event of a ContentListView, the code contained in this class loads the document referred in the Template property as an XSLT template, and executes the transform on the XML document passed on by the virtual method GetSource(). By overriding this method in the Handlers of specific Content List View types - such as list views, calendar views, icon views, etc. -, the metadata necessary to generate the markup for the given view type can be passed to the template. In the ViewBase class, the data passed to the template is an empty XML document.

In the final product, the selection of this template file will be obscured from the user as an internal detail, but currently it needs to be selected by hand upon creating a View instance. The reason for this is flexibility for testing and prototyping, and also the fact that we were in a hurry, and had more important stuff to code. Wink For you, as a developer checking out the new interesting features of our product, this is most definitely a Good Thing.

Currently there is a single View type implemented in the system, the list view. The list view - not to be confused by the "Content List View" framework, which means the entire big thing - is the "one item per row" view all so know from user interfaces dating back more than twenty years, including those of Norton Commander, Windows Explorer and Microsoft SharePoint Server. The handler class for this View type is Portal.UI.ContentListViews.Handlers.ViewBase.ListView. The XML source used for the transform is the XML formatted list of columns to be displayed in the view.

Editing the template

Now, the User Controls used as the instances for List Views were designed to be user-modifiable. The ClassBehind implementing the logic of the View type contains references to well-known control IDs. Any User Control markup containing the needed controls of the right type with the right IDs will function in this system.

However, the markup of a View instance should - and in fact, can - only be modified through the XSLT template. Any changes to the instance markup itself would be overwritten during Save. To give you a taste of how this works, let's have a look at the built-in template for list views: /Root/System/SystemPlugins/ListView/Templates/ListView.xslt. (This path may change in later releases.)

This is the main template in the XSLT file, describing the outline of the markup. As you can see, we have decided to escape all ASP.NET markup in CDATA blocks. This was necessary to maintain readability and simple editing, as ASP.NET code is non-xml and contains lots of special characters, and so doesn't play nice with XSLT at all. Note how the ClassBehind SenseNet.Portal.UI.ContentListView.ListView is referred in the header, and also note the two known controls: the sn:ListGrid and the sn:SenseNetDataSource. (The ListGrid is a wrapper over the ASP.NET ListView webcontrol, adding JavaScript for visual and behavioral effects. The ClassBehind will accept standard asp:ListView controls without problems.)

To create a new look for your ListView, try creating a copy of this template as MyListview.xslt. At first, try changing the sn:ListGrid to an asp:ListView control without further modifications. Now, take one of the existing List View instances under the demo document library, and modify its Template to MyListView.xslt. Upon saving, the new template will be used to regenerate the markup. On viewing the document library with this View, you will see that the Javascript effects have disappeared.

Further things to play with:

  • Add additional HTML markup to the view.
  • Try to convert the list view template to use an Unordered List instead of a tabular layout.
  • Add an additional, declarative ASP.NET server control to the view.
  • Try databinding it to the SenseNetDataSource.
Comments are closed

Welcome to the blog!

Sense/Net ECM is ever evolving. Community means the world to us so we want to keep you apprised on what’s happening on our side of the woods. Want to make us happy? Add a comment and tell us what you think!

Month List