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).
A recent comment by Martin Davies to this short post inspired me to take a subject that is always going to be a marmite one with us as Sitecore developers. So I will start by saying, firstly – this is not a dig at Martin in any way, I have met many developers that share the view made by his comment and that, this is very much subjective and a presentation of my view as a counter proposal – I personally have changed my mind a few times on this subject.
A ‘page structure’ as you Martin eludes to in his comment, is for my mind at least a collection of items which have presentation (generally making up the site map as we see it), as such (for me), it is a content structure like any other. I have seen on my travels both ‘page’ content structures with non-page items and ‘page’ content structures with items. I personally don’t feel the need to enforce a user to not put items without layout in some other place if the most logical place is potentially to keep it close to the item in question. I would say though – we as developers (and often users) like to see the world in our little silo’s and we can (if we think about it) get a happy medium. I will however qualify this further by looking at specific use cases, so lets consider some real world examples:
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.
This is possibly gonna be the shortest blog post I will ever do, but possibly one of the most useful tit-bits I have found in the Sitecore CMS. Ever wanted to force a user to select a datasource that is relative to the item its being used on ? I have LOADS of times, and after a bit of digging I found this:
Simply setting the Datasource Location to ./ (and I believe any relative path) for your renderings / sublayouts allows just this!
Every day is a (Sitecore) school day !! 😀
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.
Ok – so in Rules Queries Pt I we looked at the basic idea of Rules Based Queries for Sitecore. I followed this up with Rules Queries Pt II and we looked at how we can get results from a Rule we have defined. In both of these examples – I was mainly covering the idea behind the solution. Lets take that a little further and have a little think about WHERE we can actually use this functionality in our Sitecore sites.
For those who dont know, you can find Rules Queries for Sitecore here on Github
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.
Building a navigation system for a news or blog based on years and months (like an archive as an example) requires that we know what years and months are available for:
- The top level – as in when we open the home page
- Expanded – whenever we are viewing a month or article page and need to expand accordingly
- Dynamically – when we need to build the navigation in one shot, perhaps as an accordion or similar.
Note – we are assuming the following structure:
Its possible to code around these by doing Axes calls on the current item and getting the parents and siblings but this doesn’t scale well. Especially if you need to start dropping into sibling months to hide and show depending if they’re empty or not. And we haven’t even talked about languages.
An alternative approach is to use your Lucene index and scan it for all your news items in the current language and group them by year and month and store counts for each. Then you can cache this for even more speed.
In my previous post I talked about the impact of how Sitecore runs and the tradeoffs that has when using Sql Server. These aren’t bad points but they do mean you have to be able to peek under the hood to keep everything running as best as you can.
So now I’m going to share some of the procedures I use to help me maintain the databases I’m responsible for. Its worth noting that I’m no DBA. I’ve been using Sql Server for years and a combination of curiosity and my employers needing someone to step in and figure things out has motivated me to pick this topic up. I’m definitely standing on the shoulders of giants in this area but we all have to start somewhere.