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

Advertisements

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

In the last post Unit Testing On Sitecore Pt I I took a brief glimpse into some of the common barriers faced when trying to look at Unit Testing on the Sitecore (sadly, it covers lots of similar arguments outside of Sitecore too). In this post I am going to continue on an overview of strategy on how I have looked at unit testing my code.

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.

Conclusion

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.

Don’t Fight The Framework – Sitecore’s built on Sitecore so build your site on Sitecore.

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.

Continue reading

Don’t Fight The Framework – Sitecore Presentation

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).
Continue reading

Don’t Fight the Framework – Sitecore Tooling

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.
Continue reading

Dont Fight The Framework – Sitecore Events and Workflow

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.

Continue reading

Dont Fight The Framework – Introduction and Overview

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.
Continue reading