Don’t get me wrong, I love writing XSLT, but lately I have been using it less in our business apps (though I still use it in some LAMP based sites I maintain that have high traffic but interaction-wise are much simpler…)

I’ll have to find some time to write about these things as last few years have been quite busy on these fronts for me!

great post, thank you

I’m myself developing a component based web framework that uses only XSLT for templating and it has truly been the right choice. This blog post gives me hope that I’m not the only one who believes in it.

I think XSLT separates layers from just right point, making components themselves junit-testable. Also, because the XML is the only source for the templates, components can be mocked and layout can be designed or tested without actual functionality at backend.

I’ve been using Symphony CMS (not to be confused with the Symfony framework) which natively uses XSLT for all it’s templating. It’s an absolute joy to use.

Since writing this post, I’ve been working much more on a very rich client app for a backoffice use. Some installations can require immensely complex forms of 2-300 fields! Admittedly I do use XSLT to generate it as the form layout is configured in XML, but many other parts of the UI that need rich interaction are not XSLT, and as you say, for static sites, or mostly content oriented sites, XSLT still feels like a good way to go. ASP.NET MVC certainly looks powerful too but I’ve not had enough experience with it myself to comment further.

I still have to do that unit test post I promised

Since I last commented I have developed a custom CMS + CRM system for a client using ASP.Net MVC, ADO EF, and… you guessed it… a custom XSLT view engine. Now I am working on a second iteration (in my spare time) for myself which I hope to open-source parts of one day. I am back to contracting on a clunky old ASP.Net Web Forms project again which has only made my torch for XSLT burn brighter!

A couple of observations for Anton:

One of the most powerful aspects of using XSLT as a templating language is the ability to take an object-oriented approach to template code as Anup put me on to in the article above. Templates can be imported and overridden which saves a lot of time and code. I have not been able to achieve the same in Web Forms without it getting really clunky.

XSLT templates are great for what I call “static” web pages, i.e. homepages, product details, product lists, web pages without complex forms. Have a look at this site to see what I mean: http://www.eatout.co.nz. I no longer use XSLT templates for “web application” pages with complex forms as it just takes too long. ASP.NET MVC 2 with strongly typed HTML helpers and Data Annotations is the way to go for complex form development in my opinion.

I have not and would not attempt to use XSLT templates in an ASP Web Forms project, you would spend all day trying to munge control state and viewstate, ID problems, arrrrrrgh. Try MVC!

XSLT is perfect for the “V” in the MVC when you need to generate rich content loaded pages. My only caveat as mentioned above is where you need to develop a lot of forms. I switch between view engines in my projects depending on what sort of page I am generating.

- Daniel

I migrated our entire UI to Coolite instead (which is .NET framework to generate Ext.js based output). So in large parts I have not used XSLT but Coolite — the end goal is the same — as much control as possible, which Coolite gives because anything it doesn’t support, the Ext JS framework either does or you can augment it with JS. (I’ve been meaning to write about this for months, but I barely get time to attend to this blog lately!)

That said, some components are still XSLT, and they generate HTML which integrates well with Ext JS. Of course, the problem of form controls persist, potentially.

Ah, just a thought: ASP.NET4 may be an option if you are able to upgrade (though I’ve not tried it yet) — because you can control how the ids are generated much better, which means you could then generate your output with XSLT and then process it on the server side as usually (hopefully!)