Wednesday, April 22, 2009

Sitecore – One man’s opinion

I recently spent about 6 months building a web site in Sitecore 5.3.2. As this was my first time using Sitecore I wanted to put down some thoughts I have about the platform. While there was definitely some very frustrating aspects to Sitecore there are also so very slick and cool things about it. While the install I was working on was version 5.3.2 I took a trip to San Francisco to get certified in version 6.0. 

Learning Curve

Sitecore is build on .Net, XPATH and heavy use of XSLTs. If you are familiar with these technologies the learning curve for Sitecore is not to bad. I had a development team of 5 developers offshore. The team was able to get up to speed on Sitecore in about a week. Really the trickiest part of Sitecore to learn is the administration UI and the use of templates, masters and standard values (these are all Sitecore objects). You really need to think through how you will use these objects.

The UI

The UI for Sitecore is pretty interesting. It is all browser based. When you login to what they call the “desktop” interface it looks like you have a windows desktop sitting in your browser window, and sure enough this is how it acts too. There are a lot of tools available to you in this interface. All the tools work pretty well. The only area I have to complain about is the installation wizard. This tool lets you import packages from other Sitecore environments. This process moves Sitecore items (and even physical files) from one environment to another. The process works well with small packages, but (and this can be a big but) if your packages get large the process is really slow, time consuming and error prone.

The API

The API is actually really robust. We were pleasantly surprised by how robust its API was. There was not anything we needed to do that we could not find an API for. 

XSLT

All the content data you create is stored in Sitecore in XML format. In my opinion using XSLT to transform XML data for UI display is pretty slick and a great way to do UI and content separation. You can make Sitecore API calls in your XSLTs using Sitecore’s built in XSLT extension into its API (the documentation for this though is week and you are normally left looking at standard code behind API calls and guessing how to create that call in an XSLT format).

Overall the XSLT ability in Sitecore is impressive but you have to beware that when you have large Sitecore content trees the XPATH calls in your XSLTs to get your data can get slow really fast. When possible it is best to use Sitecore’s search engine to pull data from large content trees. XSLT extension are a great way to do this.

Moving it, Testing it and Source Control

This is really the area I have the most complaint around Sitecore. The nature of using a lot of XSLTs makes unit testing hard to do. Sitecore does not make this any easier given how the XSLT pages are dependant on the Sitecore datacontext object. You can mock up an datacontext object for unit tests but it is really slow to instantiate. You are still then left to create your own XSLT unit test framework. In our case 90% of our UI was created using XSLTs. Sitecore also provides no build in approach to unit testing for its objects. So when you create a template there is no out of the box solution to unit testing it and making sure default values really do default correctly.

Once you have created everything in your development environment and you are ready to move it to your test or production environment it can get interesting. You can create a package to move all the Sitecore objects and the physical files. This can be a large package an when trying to move from an offshore environment to an onshore environment can cause issues. I have also found Sitecore package installation to be unreliable (Sitecore objects will install corrupted sometimes).

Sitecore also has no source control. Everything you create for sitecore (even xslt, aspx and ascx files) have a Sitecore item associated with them which is stored in the database. All the templates, masters, standard values, etc you create for your Sitecore site is all stored in the database. The only source control you have for these items is a database backup, and let me tell you now, you will need this. The Sitecore database likes to become corrupt. The UI is not sophisticated enough yet to stop you from doing something that will corrupt you database (easiest way this happens is you set up your template inheritance so as to create a circular reference. Once you do this most likely your only way back is to restore a backup). 

No comments: