Glass Mapper – Agnostic IoC Source

Just a very quick post

This evening I released the source for Glass Mapper running on Agnostic IoC in a more useable format.

You can find it here

This is a great opportunity to get to grips with how Agnostic IoC can be used (especially with Sitecore) to give your modules the flexibility you desire them to have.

Please do feedback on your experience.


Sitecore conventions – build your own pipelines

This post is a follow up the post on using workflow I wrote a little while ago. You can read it here.

When you look deeper under the hood you’ll see that Sitecore does quite a lot of things via pipelines. A brief scan of the web.config will show a wide selection ranging from logging in, begin request, rendering fields and so on. These pipelines make it very simple to define a process and to support customisation and patching of that process. As a consequence its something that can be quite useful to include in our own code when we need to perform our own custom steps.

In the previous article, I wrote about how I was talking with another developer about sending newsletters from Sitecore. The original third party had done this as a publish step and checkbox. So the editor would check the box, publish and then the custom code would uncheck the box, save the item and then send the email. However I discussed how there were a number of issues with this approach. In this article, we’ll build on this and see how using pipelines can help.

Continue reading

Life Through A Lens – Unit Testing your .net code using Glass Mapper

So now I have gotten my first couple of Sitecore User Group presentations out of the way – I thought I would actually continue on my journey of showing how I use Glass Mapper on the Sitecore platform in real world application.

As you will see from other posts I write – I am very much a TDD advocate. I find it helps focus my mind much better than simply writing code ad-hoc. Also – I hate testing, but love coding – so what better way to get my testing done than coding.

In choosing an ORM, I believe this should be one of your primary criteria since you are going to take some sort of performance hit with it being in the way and for me, trying to justify as just being ‘prettier’ code doesn’t really cut it when you are presenting it to a wider team.

With this in mind, I thought I would kinda tie these two together and look at how I use Glass to perform unit testing on *MY* code.

Continue reading

Don’t Fight The Framework – Unit Testing On Sitecore Pt I

Before I can proceed on in the Life Through A Lens series of blog posts, I thought I would cover something that has been somewhat of a bug bear of mine since I started working on the Sitecore platform, this is Unit Testing. I wanted in particular to address some of the misconceptions with unit testing and on using Glass Mapper in unit test scenarios. I have been using TDD (and as we all do Test After Development) since around 2007 and have learned a lot in this time. Due to this – I have decided to write this post before continuing with the Life Through A Lens Series to give a backdrop of what I feel is a key idea behind unit testing. I feel it is really important to cover off some of the classic TDD mistakes before I get involved with actually demonstrating how I use Glass Mapper to solve some of these problems.

I will before I go any further give a massive nod of the cap to Simon in his improvement of my knowledge in this area. I did know some things on this subject, but his patience and teaching allowed my knowledge to progress significantly beyond where it was at a rate quicker than it would have done otherwise.

Ok, so with the above in mind, I will move on to some of the most common phrases I hear from developers / managers ( / whomever ), these are usually in response to my first day questioning of ‘What unit test / mocking frameworks do you guys use?’. The answer of ‘none’ ( I don’t know why ) still offends me.

Continue reading

SwitchMasterToWeb – updated for content search & analytics

A couple of weeks ago I was tasked with setting up our UAT environment, in doing so, I duly dug out the latest copy of the Scaling Guide for the appropriate version of Sitecore, and of course, dug out the trusty SwitchMasterToWeb.config.

So, some hours later, I pushed all the necessary code for our UAT content management and content delivery servers. I was disappointed to find that our indexing was not being built on the content delivery nodes. I eventually tracked it down and found that it appears to be the index update strategy. After patching it out

My Complete File

So here is my version of the switch master to web configuration

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="" xmlns:set="">
      <setting name="Analytics.DefaultDefinitionDatabase" value=“pub“ />
      <site name="shell" set:content="pub" />
      <site name="modules_shell" set:content="pub" />
      <site name="testing">
        <patch:delete />
	  <site name="MySite">
		<patch:attribute name="database">pub</patch:attribute>
      <param connectionStringName="master" set:connectionStringName="pub" />
      <database id="master">
        <patch:delete />
      <database id="web">
        <patch:delete />
	  <database id="pub" singleInstance="true" type="Sitecore.Data.Database, Sitecore.Kernel">
          <obj type="Sitecore.Data.$(database).$(database)HistoryStorage, Sitecore.Kernel">
            <param connectionStringName="$(id)" />
                <patch:delete />
      <agent type="Sitecore.Tasks.CleanupFDAObsoleteMediaData">
        <databases hint="raw:AddDatabase">
          <database name="master">
            <patch:delete />
      <agent type="Sitecore.Tasks.DatabaseAgent">
         <patch:delete />
      <agent type="Sitecore.Tasks.DatabaseAgent">
         <patch:delete />
      <agent type="Sitecore.Tasks.DatabaseAgent" method="Run" interval="00:10:00">
        <param desc="database">core</param>
        <param desc="schedule root">/sitecore/system/tasks/schedules</param>
                <!-- OPTIONAL FOR CHANGING TO PUB DB -->
		  <param desc="database" patch:instead="param[desc='database']">pub</param>
		  <patch:delete />
			<index id="sitecore_master_index">
                <!-- OPTIONAL FOR USING A PUB DB -->
			<index id="sitecore_web_index">

Please note, this version also changes the content delivery servers to use the ‘pub’ database which we have set up as a publishing target to allow the content editors to have the ability to view a pre-live version of the content by publishing to the web database.

Sitecore 7 Search – Searching By Inherited Template

After reading a great article this article from a former colleague (Richard Seal – Lead Sitecore Architect @ LightMaker US), I remembered that I to had solved this issue slightly differently some 12 – 18 months back using (originally Lucinq and then) the stock Sitecore 7 search. Non-the less, it fits a lot of what I have been saying in my Don’t Fight The Framework series – in particular – Please Don’t Base Your Code on Exact Templates, so I thought I would cover it again for those who don’t already know.

The problem is that Sitecore doesn’t ( / didn’t) provide a default way of searching for item’s based on their template inheritance hierarchy which means that normally in the out of the box solution you have to search on template (breaking everything I have said in my previous article above). This can be particularly useful for example if we wanted to return ‘All News Articles’ in our Site but you actually have implementations of ‘Press Release News Article’, ‘Industry News Article’ and ‘Budget News Article’

This article describes how I have achieved similar to Richard’s solution has done with Fortis (sorry Richard – I am a Glass fan 😉 ) with the stock Sitecore 7 Search.

I do have to note that I believe Sitecore (at the time I wrote this code originally) provided a similar field in it’s default configuration, but when I wrote this, it was broken (from memory, it only returned the first three levels or something).

Continue reading

Life Through A Lens – Component Parts

So – following on the first part in my series on how I have been using Glass Mapper for Sitecore in the real world.

Glass Mapper
Just a couple of quick notes on Glass Mapper, the Glass Mapper developers have done a great job of writing tutorials on most aspects of Glass, and I expect with recent developments on the project, this will only get better, so please check them out at

Firstly – Whilst Glass supports using classes for mapping, I almost always use interfaces to represent my model objects, this is due to their multiple inheritance structure and it allowing better representation of the templates on which they are to be based.

Secondly – I almost always use the fluent configuration API – however… I almost always choose to configure this using my Glass Mapper Maps project (described below)

Finally – I like to turn the Automapping feature off for the most part, this is probably because I am a control freak :D.

Glass Mapper Maps
I have been in many discussions with the developers at Glass and I am hoping that this is one of the improvements that they will consider rolling into the product as a whole. Whether this is the case or not – here is what they are and how I use them.

Glass Mapper Maps are a neat solution to isolating the domain objects for use with Glass Mapper. Generally in practice, I start off by creating 2 projects in Visual Studio, these are:

  • xxx.Model
  • xxx.Model.Mapping

In xxx.Model, I would add my regular domain objects – so, ISitecoreItem, ITitleAndIntro : ISitecoreItem, IMetaData : ISitecoreItem

Agnostic IoC
Agnostic IoC is an abstraction layer to allow modules to utilise an unknown final IoC framework, this means that I can perform my registrations and resolves against Agnostic IoC and it in turn performs them against the container of choice. It does this by means of Nuget Packages.

With Glass Mapper, this means that I can use Glass with multiple clients complying with their restrictions of IoC container – be it Autofac, Unity, NInject, StructureMap or pretty much anything else. It also has the upshot of including it in the project, so any module development I choose can also be portable.

So now when I install Glass I need at least the following Nuget Packages

  • Glass.Mapper
  • Glass.Mapper.Sc
  • Agnostic.IoC

Wherever you actually want to perform the initialisation for Glass you also need to include the ‘Translator’ package, so for example – Agnostic.IoC.Autofac. You do not need this in any projects that are not performing the initialisation.

For a more in depth description, please visit Agnostic IoC


In the next post I will be looking at getting Glass Mapper up and running in your solution fully.

May I also draw your attention to the fact that the Glass Development team will shortly be offering training and consultancy on their products which I would highly recommend if you get the opportunity.

Life Through a Lens – My Glass Mapper With Sitecore

So you are here because you are either using Glass Mapper or want to know more on how to, particularly on the Sitecore platform. This series will be attempting to relate the use of Glass Mapper to real-world scenario’s which I have encountered, problems I have solved, approaches and / or idea’s on how you could use Glass Mapper in your own Sitecore implementations.

This is the first post in a series that I intend to run looking specifically at my experience of Glass Mapper, starting with what it is, how I use it and some common issues and hopefully a bit on TDD with Glass Mapper on the Sitecore Platform.

I will focus more on the MVC implementation during the course of the series, but Glass Mapper is equally potent and simple to implement when using purely Webforms (though I feel it’s testing benefits are more limited).

I would not knock other ORMs in this space and I hope not to compare Glass to it’s alternatives during the course of this series.

Continue reading

Don’t Fight The Framework – Location, Location, Location

Ok, so here in the UK it is a great show on property development, but for the world of Sitecore I actually mean this (It will be common sense to some, and food for thought with others). This post is more likely to help you if you are new to Sitecore.

References to items in code

There are a number of fundamental issues I have encountered over my time with various projects, and this has been mirrored by reviews on my own / others work by Sitecore themselves. I find it an increasing source of frustration to find things like:

var myItem = Sitecore.Context.Database.GetItem(new ID("{some-id}"));

This in itself isn’t the greatest sin in the world, but certainly when working on code that was not originally your own it often makes it trickier to find instances in your code. At least in this case, if the user moves the item, then the code still works. In the following case however (which I see WAY too often for my liking), move it, you lose it.

var myItem = Sitecore.Context.Database.GetItem("/sitecore/content/somepathorother");

So, simply put – add your references to a central config, be it class / xml (please don’t) or whatever, that you can reference throughout your site. I personally like the convention of SubClasses to achieve this, such as:

public class SitecoreIds
   public class TemplateIds
      public static ID MyTemplateId
         get { return new ID("my id"); }

   public class Paths
      public static string MyPath
         get { return "/sitecore/content/mypath"; } // returning as a static property means assemblies that reference this don't 'bake it in' - personal

I still prefer to store IDs rather than Guids / String representations as I find in my experience the api more often requires ID than the guids or strings, it’s no doubt a personal thing.

Template Location
So, we have covered an approach to referencing your items, what about where they actually live.

This of course is subjective, but in my opinion I like to think of a strategy like this:

  • Sitecore has default locations for a reason – User Defined beneath Templates
  • For reusable modules development, Sitecore also has folders dedicated to just such a purpose (look under system for one example)

Rendering / Sublayout location

This is a slightly moot point, but I find it quite frustrating when I am faced with solutions where developers have not isolated the renderings into the site that they belong, this I feel often stems from the belief that either.

a) Everything will be ultimately re-usable (kudos if you can manage it)
or b) They never intended to have more than one site.

Sitecore is a multi-site platform, look up the Billy Crystal style definition of assume 😀

A simple folder structure maybe grouping sitea, siteb and shared will often suffice and make life easier for us.

I personally also find it useful to mimic the structure of the Renderings in the Sitecore database, its a personal thing but I feel it helps me stay sane.


It’s great that you know where your code is, for everybody else it is a learning exercise that can be made so much easier if you follow convention, it also helps a tonne in upgrade.