in Jan, I wrote my first post on Umbraco and how to build a simple Hello World page using Umbraco. Having spent the last few months working on Umbraco, I have to say, my liking for Umbraco has only grown. It is a fairly simple CMS and unlike Sharepoint, does not complicate the whole authoring experience. You could always argue that Sharepoint is comprehensive but that’s a discussion we will save for another post.
Back to what you can do with Umbraco, there are really two major options as an Umbraco developer to build UI; XSLT and User Controls. A lot of times as a developer, the decision you have to make is which way to go. As with a lot of other design discussions, the perfect answer is “It Depends”. But during the course of this post, I will try and unravel that generic answer to some realistic scenarios. I am going to try and layout the factors that I usually consider when deciding one way or the other. Keep in mind that this post is written targeting the web form model of Umbraco and come razor, some of these could change.
XSLT
XSLT is the in-thing when it comes to content managed sites. It gives you the option of giving flexibility to the content author to change the way the page is displayed making it truly content managed.
With umbraco, you get the option of using XSLT to do almost everything you want. I have typically used the following constructs to decide if XSLT is the best fit
Fluctuating UI Changes - You think something is going to change often. A typical scenario is where you have HTML tags emitted within the macro. Though there are ways and means of getting the styling changed with css, there are times when you have no choice but to emit HTML. XSLT is a natural choice in such scenarios
Navigate Content Tree- If you have to work with the Umbraco content tree. Since the Umbraco content tree is XML, XSLT becomes a natural choice if you have to navigate through the content tree.
Compliance to Standards – There are a lot of content managed standards that are prevalent. Standards like DITA are becoming more of a requirement nowadays when authoring sites. A lot of these CMS standards depend on XML and XSLT.
When in Doubt – Yes. We all come across instances when we are not sure whether to use XSLT or user controls. In such cases, my recommendation will be to start off with XSLT unless you hit an implementation roadblock that forces you to change to User Controls.
User Controls
User controls are the most natural choice for most .NET developers because they relate to it better due to their familiarity with .NET. But with XSLT being so powerful, the use of user controls for me, is limited to the following scenarios
Code Abstraction – When you do not want site managers or authors to see the code. A valid argument is that the permissions to viewing XSLT can be restricted as well through the User Permissions but bear in mind that XSLT is file based in Umbraco so users who have permissions to access the XSLT folder can view, copy or do anything with the code. If you do not want users to see what your code is doing, stick to the user control model.
Interaction with external web services – This is one of the scenarios for which I still use User control. Theoretically, it is still possible to write an XSLT extension that talks to the web service and use that within XSLT but I think it is beneficial only in scenarios where you are using the strong points of XSLT. One more interesting approach when using webservices is to use javascript and jquery templates. You could completely eliminate a macro in this scenario by having the webservice return JSON.
Parallelism – If you want to write muti-threaded code or use PLINQ then you do that only with user controls; so they become a forced choice
Use ASP.NET Features - Though this looks like a no-brainer, the caveat here is that you can still access some of the features from XSLT. The umbraco.library does have methods to get the query string or the form variables. But if you want to check if a page is posted back or not, you cannot do that in XSLT without doing some hacks.
Unit Testing Requirements – If your project requires to have high code coverage then move away from XSLT.Though there are XSLT Unit Testing suites, they are still nascent and wont really improve your code coverage results.
Though the above list might not be exhaustive, I have tried to cover scenarios in my experience with Umbraco so far. I will be interested in knowing if there are any scenarios that you have come across that isn’t covered in this post and if you agree\disagree to the observations made in this post.
