Umbraco vs Sitecore (part I)

I recently started working with Umbraco CMS on a hobby basis and found it to be a pleasant change when comparing with working with Sitecore, which I have done for about 3 years now (since v.5.3.1).

Of course doing a real comparison on these two (although quite similar) products would be unfair to both parties as it would be similar to comparing a motorbike with a international flight based infrastructure; both are used for publishing content on the web, but there is a slight difference in size, maintainance, speed, reusability, scalability, etc.

Here I will not focus on the downsides of any of the products but rather the strengths. A strength in one product might be emphasized due to the lack of similar or only partial functionality in the other product.

Umbraco
What I found when I started using Umbraco was that it is extremely light-weight, easy to understand, use, maintain, flexible in some extent, combined with an open nice and friendly community that really supports the fellow umbracian.

Get it up and running
Its pretty easy to get umbraco up and running, through an easy and user friendly installer, and thats basically it. You even have the opportunity to install a default project called run way as a kind of structure scaffolding, that lets you get an easy start with umbraco. Furthermore the default installation contains xslt files for most common scenarios, such as menus and the like.

The structure

The structure that defines a webpage in Umbraco (normally) consists of

• a 'document'
• a 'template'
• one or more macro's

The document being the data definition element, the 'template' being the umbraco implementation of an ASP.NET masterpage (which needs to inherit from the umbraco default.master)

and macro's being xslt files that render the data and are placed within the 'template'.

These are simply necessary conventions within umbraco that makes things work. 

In the image to the left the structure of the templates display the fact that inheritance is used to nest templates within eachother, thereby making it possible to reuse master pages for multiple template types. This kind of structure is used to create variations of subpages using the same master template.


Defining the data as properties in the 'document'

Defining the data as properties in the document is extremely easy and the range of field types fit most common purposes. In the image to the right a
'Textbox multiple' (which is a textbox with multiple lines) is chosen for the particular data type.

A regular expression is added as a validation expression making the editor aware of any errors typed into the field. This validation expression also prevents the editor from publishing the field. Clever, easy to setup, easy to manage, not so easy to reuse..
It would be great to be able to add the regex to a list of available validation expressions for solution scoped reuse.




Development in umbraco

Simply using the 'alias' of the document-property (see image above) disregarding the 'tab' the property is contained within, you can easily output the data directly in the markup of your template using the following syntax:


<umbraco:Item field='aliasName' runat='server' /> 


This approach is shown in the image below:

What you notice in the image above is also the use of an umbraco:Macro construct, which lets you reference an XSLT rendering. This is very easy and a commonly implemented approach to using XSLT in CMS. The use of an alias as a reference in Umbraco makes this implementation a tiny bit smarter than for example in Sitecore. Here you do not need to know anything about the actual physical localtion of the XSLT files as you need in a Sitecore solution. On the other hand you need to know the alias because Umbraco does not offer 'intellisense'/auto-completion in this case.


It is easy to create, maintain, and further develop document types, templates, and handle all the editorial work for a developer setting up the solution. XSLT editing directly in Umbraco is made easy and I definitely recommend it, because you get instant messages when some umbraco-specific error or compilation-related occurs. Like the lack of checking the value of a variable before use in some specific situations might give you an instant - although rather strange - error message.

Also you have the ability to develop and maintain the CSS and js files for the solution directly within the administration interface. This feature - and the ease of using it - really is a great feature, which in my opinion should become industry standard.

Need-to-mention drawbacks
Umbraco does have a functionality called packages, but moving templates, documents, and content between  development environments is quite a hassle. I have not found a working approach that supports this (yet).

Language versioning of content is not the easiest thing to do in Umbraco and requires a custom solution.

Development-environment-wise it is not as friendly as other CMS opponents.

Best area of application 
Small to medium-size solutions with no super critical data

Pros
Rapid development
easy maintainable
Fast
Great community
xslt macros within rich text editor