XSLT vs. HTML based Layout (Starter Site)

Topics: General, XSLT
May 11, 2011 at 1:10 PM


I recently started using Composite C1. During Install you can setup a starter site, either with HTML based or XSLT based layout.

Is there any 'heavy weight' advantage in using XSLT based layout (which means that everything - even simplest HTML-markup - is put into a XSLT function, right?) instead of HTML based layout? The Omnicorp Example uses the HTML based layout as I see. I would appreciate some hints, helping me to make a better decision which layout approach I should use...


May 11, 2011 at 1:56 PM

XSLT is an acquired taste - I personally love it as a tool for controlling my html markup, but it is not a silver bullet and it has it's drawbacks.Note that you can also use ASP.NET .master pages for building your templates - we haven't added this feature as a setup wizard option yet, so it is a little more work getting there - but that is an option.

Here are some HTML/XSLT pros and cons I can come up with:

HTML pros:

  • Simple - anyone get it
  • When new to Composite C1, this can be an easy way to start
  • If a C1 Function on a page should fail, only the specific functionality is missing. The rest of the page render fine.

HTML cons:

  • A lot of markup redundancy - things like footer html is repeated on each template
  • No fancy logic allowed (all the pros of XSLT is not available)

XSLT pros:

  • Centralized handling of common elements eliminating markup redundancy
  • Ability to transform any markup (from functionality or user content) if needed (like "capture div's with a specific class and wrap it in more markup")
  • Ability to add processing logic where you want to.
  • You own the markup 100% - add specific markup rules for mobile devices if you want etc.

XSLT cons:

  • You have to be a fairly savy developer to enjoy this. XSLT and especially XPath is a steep learning curve.
  • XSLT can be notoriously hard to debug
  • If a C1 Function on a page should fail, the warpping XSLT function also fail - making the entire page an error page (like ASP.NET pages typically fails - one big error screen).
May 11, 2011 at 3:11 PM

Thanks for your answer and the great comparison between HTML and XSLT / pros and cons!

As I said, I'm new to Composite C1. And since I have been creating websites with "normal" ASP . NET C# so far (using no CMS) with MasterPages and UserControls, etc., the use of XSLT-functions (as a replacement for UserControls and MasterPages) is a new approach to me.

Would you say that using MasterPages and UserControl is a fully equivalent to XSLT? Or would you recommend to me to get deeper into XSLT-Coding, because in the long run it's - regarding Composite C1 - the better choice.



May 11, 2011 at 4:10 PM

I would recommend that you (at least for now) use .master pages (or plain HTML templates) and WebForms controls if you need to create new features - and use the pre-build feature packages when they do the job (they may use xslt for markup templating, but they are typically easy do modify if you know html). When you are comfortable with Composite C1 as a CMS and you need to present data already in the CMS, try XSLT on for size and see if you like it. If you do, using XSLT for layout logic could make sense,

Whether XSLT and MasterPages are fully equivalent - no, they have very different strengths. If the problem domain is narrowed down to layout logic (i.e. controlling exactly how markup will look when sent to the client) I personally feel XSLT is a spot on tool for just that. I would postulate that ASP.NET WebForms do allow for great markup control, but it can be a fight. On the other hand XSLT completely breaks down as a tool if you need anything more than 'transform this XML document into that XML document' - for instance XSLT can not do a "for i=1 to 10" or replace strings, it can just "match xml patterns" and "emit data from matches, wrapped in new xml".