This one will be a relatively quick one ( hopefully before the girlfriend finds out I am working on our holiday 😉 ). Continuing on in the Don’t Fight The Framework series, I thought I would discuss a topic that has kind of formed the more I have worked with Web Content Management Systems such as Sitecore. As me and Simon used to band about in our development exploits (usually in a faux Danish accent) – ‘Sitecore is built on Sitecore’ and it got me thinking…
The basic premise is this – we as developers are often guilty of just opening visual studio and hacking away at our latest interesting issues / projects & crazy solutions to problems. I have found particularly with Sitecore you can sometimes get a feel for how successful a Sitecore solution you have developed by how much time you spend in Visual Studio ( not including Rocks before I get some clever < Insert suitable name for smart person > piping up! ). It is my opinion that the more flexible your Sitecore build is, the less time you should be spending in your development tools, and generally, if you are spending time, its to look up how you have used the rendering parameters / pipelines / data sources etc are controlled by the user interaction and potentially what templates are expected.
I say this for the simple reason – in my travel’s in whatever capacity working with the Sitecore platform, I have had the pleasure (and sometimes mis-pleasure) of being able to work in many different teams with many differing levels of understanding of the product & the .net framework, many different source control tools, continuous integration & build servers, deployment solutions. I am required by the nature of my job to be maybe more flexible than those lucky enough to be part of a fixed team with fixed tooling, I often have to slot into a pre-existing team with pre-existing ideas, sometimes to mentor, sometimes to lead and almost always to develop. This has allowed me to see many approaches to Sitecore solutions (and obviously from my posts on here, form different opinions on their validity / merit).
Build your solutions in Sitecore
I have found through this experience, that the most successful solutions I have worked on, are the ones that I can basically use Sitecore (and the code I have written usually early on in the project) to build the site, with very little need for Visual Studio (there are obviously notable exceptions to this).
Ok – so what sort of thing are we talking about?
To cite an example – I have talked previously about inflexible design in presentation, having worked on way too many solutions where you get hard coded references to renderings or sublayouts that then have the child sublayout ‘require’ something to be in place in its parent sublayouts, this has been particularly prevalent when you have things like product detail pages, product searches and ‘find our stores’ type functionality. Often it will be to separate out the ‘technical info’ or ‘related products’ sublayouts for example.
Why not approach this differently? – Let’s break it down further – Sometimes it’s nice to be able to nest your sublayouts within each other as a programmatic level – we during a large corporate build for example actually created the notion of a ‘ParameterisedRepeater’ control, which actually did pretty much the following
- Gets a set of items (this was override-able in code, so had items from multilists, children, lucene, you name it)
- Loop through the items and (if not determined by the rendering parameters) figure out using template inheritance what child sublayout / rendering to use.
- Set the value of the child sublayout / rendering path in (at the time an asp:) repeater
- Set the data source of the child sublayout / rendering to be the item as you are looping through
This leaves you with:
— Sublayout for child 1 with datasource for item 1
— Sublayout for child 2 with datasource for item 2
This approach (with a few parameters such as wrapping css class for example and a small Sitecore based template > sublayout mapping structure) meant very quickly, we had a repeater control that we could use any of the individual child controls on their own (simply by selecting the appropriate sublayout / datasource etc) and have the ease of using them in a repeater. Let us not forget that Sitecore has an extensive .Net API and you can equally set the datasource in code.
(NB: This approach did require us to slap the front end guys until they stopped unnecessarily making everything on the site an un-ordered list 😉 )
Here is a reasonable example of how we have continued to allow ourselves flexibility by using what Sitecore has to offer. There are hundreds of these scenario’s littered through our solutions.
From these kind of mistakes, I have begun to conclude that one of the most dangerous phrases in Sitecore development is – ‘the user will never’. Always try to consider – ‘what if they decide to’ – it might not be now, but the amount of times I have unpicked code from developers assuming the ‘user will never’. Build your code to allow you change it later. As per great agile principles, we shouldn’t try to second guess where the product will go from this point on.
Don’t ignore .Net
This kinda leads me nicely on to the next (and I will keep this brief) topic of .Net coding in Sitecore solutions I have worked with. I will preface this with – I am no coding god, I make bad design choices sometimes, I definitely screw up simple tasks on occasion, but I strive all the time to improve for the sake of myself and every other poor dev who has to work on my code. Upfront also – apologies to the converted, but this needs to be preached 😉
Sitecore is absolutely a .Net based product, as such, OO principles still apply, patterns are still valid, the requirement to stick solely with what Sitecore gives us out of the box is certainly NOT there. So many solutions I work with show very poor knowledge of basic programming idioms, patterns & practices. I have seen WAY too many times, basic errors such as:
- Not closing / disposing SQL connections (note – it’s one of the few instances in the .net framework that close != dispose)
- Static factories where IoC containers would have been better
- No unit tests
- Multiple calls to heavy procedures due to bad decisions
- Failure to cache data or even more basic – lazy load
These kind of things in particular give Sitecore a bad name (one particular client I have worked with required in excess of 6 servers to keep their installation of only 25,000 items running). The client perception was that it was Sitecore that couldn’t cope – when in fact, within 40 seconds of opening the solution I had identified no less than 6 places where connections were not closed, and further occasions where the failure to use try / catch correctly meant that if the code excepted then the connection is not dealt with.
So I urge you to do at least the following if you haven’t already (and if you lead a team, have them do it 😉 ):
- Pick up a copy of just about anything by Robert C Martin – I recommend agile principles, patterns and practices in c#
- Pick up a decent book on basic patterns (the Head First series were not bad) – I don’t think they are the only way, but having the knowledge and not using it is better than not having it 😉
- Learn and experiment with basic tooling if you don’t already, IoC containers, Build Servers, Deployment Servers, PM tools everything
As described above, the aim I reckon is to (as much as possible) build your solution to provide the greatest level of flexibility, this will usually make your life easier later on. If you get towards the end of a build and you’re still hacking away at existing code, not adding new widgets it can be a real indicator that you didn’t get it so right. If the user comes to you and says ‘we need this control to now do x’ its a great feeling to say, ‘yeah sure – it’ll take me 10 mins to create a new type of datasource’, rather than go unpick bad decisions.
In the respect of Sitecore also, try to build all of your controls to be standalone but usable by wrapping controls – try to never tie these together. The number of times in my career where the client will say – ‘can we just have this (from whatever page) just here (on the new page)’ is unbelievable, and it’s so much easier if your controls stand up on their own. Module loading frameworks such as RequireJs can also help make your life easier on this front.
This article is part of the Don’t Fight The Framework Series