.Sitecore

As I’m mentioned as a co-author on this blog I better author some. So here it is! If you just came fresh into the office and didn’t have any coffee yet I’ll advice you to do that first. I’ll be here when you’re back. It’s gonna be a lot of text and no pictures. Don’t say I didn’t warn you!

Today, when looking for some important document, a came accross my first Sitecore certificate dated October 2004. Almost 2 years ago now. Me and an co-worker got teached by Steven Singh from Codehouse.dk and immediatly after started working on our very first sitecore website, still in use today: www.loopbaan.nl. This was also the time Alex first came to work for Lectric and joined are team. Alex and I made long hours to complete the site. Working with this great new product, fully integrated with .NET far better than the lame asp or VB6 our co-workers had to program in. Fast forward to present time. We have created over a dozen sitecore implementations with sitecore 4 and sitecore 5. Alex is now the sitecore master and for myself. I’m teamlead of the support and maintance department. We have a small team of 4 people responsible for the projects after they are in production. And at this supportdesk we keep getting back the same kind of issues with sitecore sites, resulting in the best practices described below. Most of them are propably well know off, some of them are probably more C# best practices. I may miss a few. Don’t hesitate to comment on them!

Treat sitecore data is if it comes from a database: When you got data from a database, everybody knows you got to check if it’s really there. However when people retrieve data from the Sitecore API they just assume it’s there. Invoking methods on Fields even when the field is not made mandatory in the template. This is the single biggestbproblem we get reported. When a user creates a new item and doesn’t fill in the required field suddenly the site stops working with an ugly nullpointer exception when the code tries to acces it. Check your items and fields for NULL values before invoking methods on them. It will avoid a lot of problems.

If you can do it in XSLT, do it in XSLT: Maybe it’s harder to write and maybe you don’t have a nice debugger (in SC5.3 you have a great tool btw) but building your site in XSLT makes maintenance so much easier. If you build a sublayout, and it has an error you’re screwed. The website suddenly stops functioning. According to your logging you may have or may not have debugging info. In the worst case you first have to build an debug build of your DLL. Upload it. Discover on which line the error is. Fix it. And upload it again. With every upload you have to restart the site. Causing the editors to lose their work. When you create your renderings with XSLT and have an error you get a nice little image. Describing want went wrong. You can alter the XSLT and try things out without the need to start and stop the webserver. The site still functions and the editors won’t loose their work. It’s a win-win!

Use errorhandling & defensive coding:
If you do stuff, asume the worst. Asume the disk is full. Asume the user entered faulty values. And handle this situations well. Use try/catch a lot! And don’t use an empty catch statement. That’s error ignoring not error handling. If you don’t know what to do with an error do the minimal and log it somewhere. It’s all part of defensive coding. Also don’t make statements like: field[value].equals(“File”)? value.other = “yellow”; value.another = blue; If you have a nullpointer or an error on that line you won’t have a clue. You make think your great because you can write difficult statements. The people who maintain the code will get frustrated and will look your name up in SourceSafe and will tell everybody you code like a monkey. (and they are right!)

If you need an item to exits, make sure a user can not delete/rename it: Regulary we use the web.config to set paths to items we need in certain applications. It’s ok to do so as it makes your solution more flexible. However make sure that user’s can not delete the said item or create your code in such way that it handles the situation correctly! User security is mostly an forgotten item. In comes in position #2 on the list of most encountered problems: “I’ ve just renamed my site root to something more usefull and now it stopped working!”

Build for easy release: Sometimes you have to use layouts with DLL’s. When you add functionality to a site which is already in production this may cause a problem. Your Layouts may need the new codebehind, the codebehind may need some items, and the item’s may need some layouts. This is a hard one to solve. So plan ahead! make your code as independable as possible and try to see the concequences. Bringing the site down for an update of a layout so they use create items with iframes now won’t make your customer happy.

Have fun:last but not least. Have fun! You’re working with a great product!Rule #2: there’s always time for coffee! So if you’ve to got here you earned yourself another cup! Enjoy!