public partial interface IPageTitles : IGlassBase { bool DisplayInMenu {get; set;} bool Dropdown {get; set;} string Icon {get; set;} string LongTitle {get; set;} string ShortTitle {get; set;} string StrapLine {get; set;} }This makes it very easy to find the model you want to use because you just have to look at the name of the template and then find the matching class.
public interfacet Content : IPageTitles, IMetadata{ }
Template Models are easy for new developers to understand and it is easy to trace where the data is coming from however it does have certain limitations:
There are several scenarios when Template Models have a clear advantage:
Rendering Models are models that are designed to contain just the properties that required by a rendering. For example lets create a model that represents the breadcrumb at the top of this page:
public class Breadcrumb { [SitecoreQuery("ancestor::*[@displayinbreadcrumb='1']", IsRelative = true)] public virtual IEnumerable<Breadcrumb> Ancestors { get; set; } public virtual string ShortTitle { get; set; } public virtual string Url { get; set; } }
You can see that this model contains just the properties we need to render the breadcrumb. The model is also responsible for retrieving the ancestor items removing the need for any additional code. My model has now become a bit smarter and part of the logic that I might have had to put into a controller or web control is now in the model.
As a result of not having to represent Sitecore's multiple template inheritance I am now free to use a class. This allows me to start adding logic and methods to my model, for example I am going to update my Breadcrumb title so that it checks if a ShortTitle has been supplied and if it hasn't then use the item's name:
public class Breadcrumb { [SitecoreQuery("ancestor::*[@displayinbreadcrumb='1']", IsRelative = true)] public virtual IEnumerable<Breadcrumb> Ancestors { get; set; } protected virtual string ShortTitle { get; set; } protected virtual string Name { get; set; } public virtual string Url { get; set; } public string Title { get { return string.IsNullOrWhiteSpace(ShortTitle) ? Name : ShortTitle; } } }
Notice that I have made the ShortTitle and Name properties protected and exposed the Title property, by doing this I make it clearer to anyone using the class which property should be used for rendering.
We can see that the Rendering Model gives a lot more flexibility in how we map our data and also in how we manipulate it. Rendering Models can easily pull in data from other items in Sitecore using configuration such as SitecoreQuery, SitecoreNode, SitecoreChildren and SitecoreLinked. The properties that you expose via the Rendering Model also make it clearer what information should be available to the rendering when another developer looks at the model.
However Rendering Models still have some limitations:
Despite these limitations Rendering Models have the advantage that they can be used everywhere. Almost all the code you will write in a solution is a view of your data in one manor or another.
Glass.Mappper.Sc is supported by the generous donations of the Glass.Mapper.Sc community! Their donations help fund the time, effort and hosting for the project.
These supporters are AMAZING and a huge thank you to all of you. You can find our list of supporters on the Rockstars page.
If you use Glass.Mapper.Sc and find it useful please consider supporting the project. Not only will you help the project but you could also get a discount on the Glass.Mapper.Sc training and join the Rockstars page.