So, continuing on the theme of the previous posts, in particular Don’t fight the framework part I I thought it would be a good idea to cover the presentation side of Sitecore in a little more depth, with a particular focus on how bad decisions can affect implementation in the future. I chose this topic because from day 1 (as an umbraco and e-commerce developer and beforehand) it has been my belief that one of the most important part of any system is the users (lets face it – fantastic architecture with a crumby user interface means its only the dev’s that use the software – did someone say Oracle).
I could probably write another 10 – 20 posts just on the subject of the presentation side of Sitecore, but I have tried to distil some of the key points for this series and in particular the common pitfalls and/or lack of knowledge that leads us to make bad decisions (as with all these sorts of posts – of course – I too have been guilty).
Something I’ve been involved with quite a lot is making multi-lingual sites work in Sitecore. Building a multi-lingual site touches on quite a lot of parts of Sitecore and really pushes your understanding. So lets start with the basics:
- Items – versions and specific attention to shared, versioned and unversioned fields
- Deciding whether to have separate trees per language or blend them together in one tree (or even a mix)
- Translating content and whether you need to fall back to a language if a version in the current language isn’t available
- Other niggles we’ll come to
Following on in this series, I found another topic I thought I would cover off from my travels. I guess the theme for this is that ‘just cause its the normal way, doesn’t mean it’s the ONLY way’ with a particular focus on choosing the right tooling from the options that Sitecore ships with. The following is an example of a consistent trend I have encountered and goes a little something like this.
Tree Traversal vs Lucene (or Lucinq or SC7 Search)
Firstly on this point, I will say this – Why are developers so scared of Lucene?? its an amazingly fast solution to a raft of problems and hyper fast to boot. People are quite quick to be jumping up and down about NoSql solutions (which I also love), but as developers you can solve similar problems with Lucene, it is in essence a form of unstructured data store and very mature.
Nat and I have worked together for quite a while now and Don’t Fight the Framework has become a running meme between us almost since day one.
In this post I thought I’d take a side step on this and talk about an example of going against best practise. Admittedly, best practise is often convention based so it can be hard to know what is the right and wrong way. As in many cases there is the right way and the better way, which is usually the case in Sitecore.
Before I continue, I want to point out that there is nothing wrong with creating event handlers for saved and published events. Running code from the rules engine, moving items, creating items etc are all good examples (and I use them). But you must be aware of the consequences and code accordingly. That said, they can also used for the wrong reasons as we will discover.
After reading Simon’s post on Sitecore Template Inheritance and continuing the vein of my thoughts on implementation starting with my thoughts on Sitecore Visual Studio solution structure I thought I would write a few words on when / why we might choose to extend Sitecore in different ways.
So many times I hear from clients about how Sitecore is running slowly, or Sitecore takes ages to save something. I end up repeating myself so often – ‘Sure, Sitecore has some issues in some area’s, but for the most part, if Sitecore is running slowly, its cause the development isn’t right in some way!’. In short, Sitecore has many sites in the wild with over 200,000 items (per language) of content running absolutely fine and dandy on small server clusters. Sitecore CAN do it, if it can’t there is a reasonable likelihood that in fact the developer hasn’t thought enough about what they are doing and whether its the best way to do it.
Inspired by Nat’s post on inspecting what templates an item is inherited from, I wanted to post my own thoughts on how you would use this in practise. Often when I review template structures in Sitecore I get a feel for how well the template developer has of Sitecore presentation and ensuring flexibility.
A good practise that I advocate in these review sessions is to consider templates as abstract collections of fields. We then extend this concept to consider anything we make a content item out of as something that groups abstract groups of fields together.
What is important, here, is that I haven’t mentioned inheritance. As Sitecore is based on .NET and the single inheritance model, developers can often think of Sitecore inheritence in the same way.
Ok, so this will probably seem like a rant at first, and to some it will be preaching to the converted, but I cannot count the number of times that I have seen this approach in code.
if(item.TemplateName == "my template")
if(item.TemplateID == new ID(""))
In Sitecore, we have the great strength and flexibility that is template inheritance, and multiple inheritance at that. Most of the components we develop often contain logic that checks for the availability of field values and the like, and lots of code I have seen created by developers will have direct references to a particular template – please don’t :D.