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.

Advertisements

One thought on “Don’t Fight The Framework – Location, Location, Location

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s