GUIDs or Names?

It has been a while since my last post. This is my last week before I go a week on holiday, actually my holiday starts on wednesday. Tomorrow is just a normal day at the office. Wednesday, I’ll go together with one of my collegbues to a seminar of Atos Origin about Visual Studio Team System. Wondering what opportunities come out of that seminar for our Sitecore team.

This post actually is all about the usage of Names or GUIDs of items. This is, because of I’ve seen lots of codesnaps where collegues and even the support team of Sitecore does use GUID’s and Names trough each other.
For example: most of the time you have public content folders and non-public content folders in you datanodes. What the f*** are you talking about? Well I’m going to explain it a bit easier: When you are going to divide your content, such as ther normal menustructure, you always have those non-menu-items or non-content-items such like disclaimers, privacy notices, etc. You can choose for 2 solutions to make a logical data-tree, place the non-menu-items really outside of the tree:

+ root + content + folder 1
|————————+ folder 2
|———–+ bottom menu

Or you’ll use a structure like this:

+ root + content + folder 1
|————————–+ folder 2
|————————–+ bottom menu

When creating a menu-sublayout or rendering for the first tree, you are ready in a second, for the second one, you have to do some conditional work. In my opinion, the easiest way is to make 2 different templates or masters(based on the structure you have created in Sitecore). Now you can easily look which item should be included in the menu.
So far not so heavy, do you think? Well, it isn’t so easy. I’m going to introduce a third template/master and a fourth, a fifth, etc. We we have to make it generic(hot word these days ;)). The easiest solution is adding a key in the web.config. For example: ‘MenuAllowedTemplates’. You divide the names by pipes(|). And you’re ready. Oh uhm, Am I actually? Sitecore does store my content based on GUIDs, wasn’t it? Yes, all the items, and sections of items, and fields of sections of items, etc all have their own GUID.
This implicates that we can remove the string-compare in our code and let Sitecore do the trick! Constructing is quite easy:

Sitecore.Data.ID myID = new Sitecore.Data.ID(“{11111111-1111-1111-1111-111111111111}”);

Before you actually are going to rewrite your code, I’m going to tell you that this isn’t a way of writing code and managing your website. Why not? Wel.. can you handle this config settings:

Or if you really want to make it less readable, remove the brackets….
No, this will cause only problems, for this one time please use just your Template or Master names, use different content-structures, but definitelly do not configure IDs! System Egineers will kill you, and you have to ask yourself the questions: what happens when I configure a wrong ID? Are IDs in different database the same? Etc? Etc!
When you need some full example code, please contact me, I’ll collect some for you.

As I’ve to do on daily base with this kind of stuff I’m feeling mroe and more for writing a small book: Sitecore Development, what’s good, what’s bad?! When you have any suggestions, I’m very interested.

Note: When you are going to use Sitecore XPath it’s again highly preferred to use names instead of using GUIDs. /sitecore/content/*/[name == teampleX] is definitelly more readable then:
/sitecore/content/*/[id == {11111111-1111-1111-1111-111111111111}]