In this post I’m going to demonstrate a cleaner approach of binding information to your Sublayouts by using simple Data Models.
Over the past few years I’ve been a huge advocate for utilising Datasources for absolutely everything. This is absolutely vital if you want to leverage Testability and Personlisation – and never assume that a piece of content will never want to be personalised, you simply cannot tell what the future holds 🙂
There are cases though where data does not come directly from Datasources but is the product of a Search or some other form of acquisition. Generally this is bound to a Repeater and the fields a loosely typed in terms of pulling the data out:
<asp:Repeater id="rptTest" runat="server">
<ItemTemplate>
<%# Eval("Name") %>
<%# Eval("Author") %>
<%# Eval("Intro Text") %>
</ItemTemplate>
</asp:Repeater>
This post will show you an alternative approach. Nowadays I use Data Models (or View Models?) to represent the information that needs to be rendered on the front end. This ensures that there is a strongly typed class (or data set) that contains what is needed (and no more). This also ensures that we have a consistent entity which can also interact with the rest of your code. In the instance of a Repeater, you can utilise the property ItemType in order to define which Data Model is bound to the repeater. Once this is done it makes it much simpler to pull the data out of the Datasource that is bound to the Repeater.
<asp:Repeater id="rptTest" runat="server" ItemType="SitecoreJim.Entities.Book">
<ItemTemplate>
<%# Item.Title %>
<%# Item.Author %>
<%# Item.IntroText %>
</ItemTemplate>
</asp:Repeater>
Taking this one step further
Generally when I create Sublayouts I inherit from a base class called SublayoutBase which provides a good deal of generic functionality that we use everyday in our components. I have created a new variant of SublayoutBase in which you can pass in your Model type at the point you inherit from it:
public abstract class SublayoutBase<T> : SublayoutBase
{
public T Model { get; set; }
public abstract void CreateModel();
}
Also in the SublayoutBase there is an abstract method called CreateModel(). As its an abstract method, the intention is that when you inherit from SublayoutBase the implementation for this method is required – the model is created in the place that understands how to create it. Now that we have everything in place, when we bind the Data Model to the Repeater and specify the ItemType, it makes it much easier to understand what information is bound to the Repeater and where the information is coming from.
Usage in the Page Editor
Using the methods above it is actually very easy to specify an example Datasource for our repeater specifically designed for the Page Editor. In the CreateModel() method it is a simple case of checking for the Page Editor and creating an example model for rendering
public override void CreateModel()
{
List<Book> books = new List<Book>();
if (Sitecore.Context.PageMode.IsPageEditor)
{
books.Add(new Book()
{
Title = "Black Diamond - How we started",
Author = "Jamie Little",
IntroText = "This is a great book"
});
books.Add(new Book()
{
Title = "From Rags to Riches, back to Rags and finally to Riches again",
Author = "Stewie Mcnaughty",
IntroText = "This is another great book";
});
books.Add(new Book()
{
Title = "Sense and Nonsensability",
Author = "Fred Cringer";,
IntroText = "How not to build stuff in Sitecore";
});
}
else
{
// Populate Model using data
}
}
Remember, as this data comes from a different source it would not be content editable anyway, however it’s always good practice to show a representation of the component when the content editor inserts it into a placehder
The new SublayoutBase can be found here:
This inherits from a SublayoutBase class which you might also want to take a look at.
Anyway, any comments, feel free to leave them below
Jamie Little 