Over the last couple of months, within the Glass Mapper team we have been busy considering a few things regarding the framework and decided this upcoming release of Glass Mapper should aim to improve on the flexibility of certain areas of the product as well as the ability for developers to get involved with our source more easily. Here is a run down of the key features of this new release and what it means.
SitecoreContext and GlassHtml creation
Something that I have found a little frustrating in my (now long) experience with Glass Mapper was the lack of ability to control some of the instantiation within the framework itself. This was key in 2 areas.
1 – The Sitecore Context
Internally in many areas, Glass Mapper used to rely on the SitecoreContext.GetFromHttpContext() static method. This was somewhat frustrating as sometimes this isn’t available etc. For this release we have introduced a factory to the codebase internals allowing developers to change the behaviour.
SitecoreContextFactory.Default.GetSitecoreContext(); // or SitecoreContextFactory.Default.GetSitecoreContext("context name");
In order to override the default for the whole of Glass Mapper you simply need to create yourself a new class that implements ISitecoreContextFactory in your own solution and then perform the following step in your GlassMapperScCustom.cs
SitecoreContextFactory.Default = new MyNewContextFactory(); // where MyNewContextFactory : ISitecoreContextFactory
2 – The Glass Html implementation
Similarly, the Glass Html instantiation is now driven by an overridable factory. In this case though, its on the more common DependencyResolver class since GlassHtml is not so often used in isolation within a codebase.
In order to override the default for the whole of Glass Mapper you simply need to create yourself a class that implements IGlassHtmlFactory in your own solution and then perform the following step in your GlassMapperScCustom.cs
dependencyResolver.GlassHtmlFactory = new MyNewGlassHtmlFactory(); // where MyNewGlassHtmlFactory : IGlassHtmlFactory
This change is going to be awesome for those of you that want to modify Glass Mapper’s rendering behaviour.
Due to the now factory based nature of these implementations, it is also entirely possible that you could resolve either 1 or both of these using your regular IoC container and standardise their behaviour further.
Version Count Behaviour
It was noticed (credit to James Wiseman here in the UK – sorry dude – I don’t know your public details), that the version count behaviour had a slight issue is it’s ordering. We have fixed this, but also went a step further to encapsulate the functionality into an ItemVersionHandler. This as with all things Glass Mapper is overrideable by creating your own class that implements IItemVersionHandler and assigning it as follows.
dependencyResolver.ItemVersionHandler = new MyNewItemVersionHandler(); // where MyNewItemVersionHandler : IItemVersionHandler
Also within the framework is shipped an alternative CachedItemVersionHandler, this uses Glass Mapper’s internal caching mechanisms to retain whether an item has versions. Early tests have suggested a reasonable performance improvement over the standard one, but it is not yet tested in a production instance so is considered an example implementation for now.
Lazy support improvements
Glass Lazy support has been in the product for a little while, but not really shouted about too much. For this version we have improved it a little. This allows you to add lazy loaded properties to your models that act like normal properties for the purposes of us in you cshtml (which let’s face it – is the majority of where you will be pushing your Glass Mapper properties out to).
This is of particular importance we feel to those of you who are crazy enough to automatically generate your Glass Mapper models, since (in theory at least) you pay little penalty for mapping properties you are not using.
Release build tagging
In order to provide better support and tracking for the various versions of Glass Mapper, we decided that implementing tagging on our build server would help track issues. This allows us and you guys the ability to see what the codebase looked like for your specific version, like below, which is the current beta release at the time of writing.
TDS Segregation & Update Package
A small contingent of developers (primarily those without TDS licenses) feel our use of TDS has proven a barrier to getting involved on the project. For this reason we have separated the TDS projects into their own solution and provide a Sitecore update package on our build server.
The Sitecore update package can be found on the build server as an artifact of the build.
We are hoping to soon publish a complete how-to on getting Glass Mapper up and running from source (tbf, it doesn’t take much)
It is with great regret (this one may disappoint some of our followers), that the decision has been taken to discontinue support for Umbraco using Glass Mapper. This decision was long thought about and has been taken for a number of reasons including architectural, uptake and personal. We are hoping the simplification of the codebase over the coming releases will start to make the product even better than it currently is and help vindicate us :D.