.Sitecore

This post is a good example of how your proces of building software can improve a lot over the year. Where I want to talk about is quite simple: retrieving your data from Sitecore using C# / VB or any other .NET-enabled language.

The problem:
Customers are never happy when websites do not work at all. It’s quite annoying for those guys when Sitecore delivers some the ‘UnhandledException.aspx’ or  the damn ugly yellow and red page. Haven’t tested so far, but Hans told me once, he should be able to make the server crash just because of the uncaught Exception objects. I do believe him, which makes this problem a category 1 problem: functionality AND security…

Ways to keep your customer happy:

1. Create delicious Error pages. Designers are able to let exception taste like cookies. Just by giving the exception the color of the website. Implementation can be done by replacing the UnhandledException.aspx.
2. Report to your maintenance department exception are occuring, buffer them(1 exception per hour is more then enough!), but send them. At least, log them so you can recover and reproduce it!
3. When functionality behaves unexpected because of wrong user input, just create an ugly Literal with the message such as ‘User input isn’t valid, please try again’. Crashing or even worst, a UI which doesn’t react makes the user click again on the Submit button, and on all those others… Stresstesting is preformed indeed in a way uncontrollable way!

Solution:
I’ll not say this is a solution for all but it works for 90% of our exceptions: Create a Context/Util class with method such as:
GetFieldFromItem(Item currentItem, string fieldName). Here are some examples used in the project I’ve worked on today:

/// <summary>
/// Return the friendlyUrl from an item, based on a path in the Sitecore tree
/// </summary>
/// <param name=”itemPath”>the path to return the friendly url from</param>
/// <returns>friendly url of the path, returns “#” as default</returns>
public static string GetUrlFromItem(string itemPath)
{
// set the default return value
string url = “#”

// check for null-references
if (!string.IsNullOrEmpty(itemPath))
{
// retrieve the item, based on a path
Item myItem = Sitecore.Context.Database.GetItem(itemPath);

// check for null-references
if (myItem != null)
{
// call the custom getFriendlyUrl method
url = Context.getFriendlyUrl(myItem);
}
}

return url;
}

/// <summary>
/// Get a boolean from checkbox field
/// </summary>
/// <param name=”currentItem”>the Sitecore item that containt the field</param>
/// <param name=”fieldname”>the name of the field to retrieve</param>
/// <param name=”defaultValue”>value to return when item doesn’t exists</param>
/// <returns>a bool with the fieldvalue. It returns the default value when field isn’t available</returns>
public static bool GetBoolFromItem(Item currentItem, string fieldname, bool defaultValue)
{
CheckboxField chbField = currentItem.Fields[fieldname];
if (chbField == null)
{
return defaultValue;
}
else
{
return chbField.Checked;
}
}

 

All fields are accessed using the class containing the above methods. It’s a lot more flexible. Take a look at these lines:
// call the custom getFriendlyUrl method
url = Context.getFriendlyUrl(myItem);
So we are able to preform our own formatting of the created links, for Search Engine Optimalisation for example! And, the most important, we are sure we will never return ‘null’. So nullpointer will NEVER occur.
This kind of methods should be (Unit-)tested very carefully.

Ofcourse this isn’t ‘the solution’ for all. I do always compare these small solutions for much hugher problems with the way you build an application in Ruby On Rails :
Create WebApplication With Rich Internet2 Aspects Running On Webserver

That’s impossible, Rome wasn’t built in 1 day and the same for Sitecore solution, they aren’t stable by just writing code like above! More on this topic soon as more and more people are asking for it…