Why use HTML markup in languages like ruby, php, asp.net mvc instead of XLST to convert XML to HTML?_问答_开发者

I just learned about XLST on stackoverflow today (I love how in computers you can program for years and constantly have 'darn, how did I not know about that technology' moments). I'm wondering how popular XLST it is for web development? I've worked on a few websites (using php, ruby, and asp.net mvc) but I'm not a 开发者_JAVA技巧web developer by any means.

Is the reason each web language I listed above has it's own way of marking up html (and thus taking advantage of 'templates') just to make it simpler (simpler as in more to the point and not and more geared to one specific purpose) in that you don't have to first convert what you want to display to xml and then to html? Or are there other reasons why XLST doesn't seem too popular for web development? Or am I just crazy (again most of my work is with Desktop apps) and actually it is widely used in webpages? If not in development, what do you mainly use it for?

It seems that being able to easily serialize objects in xml with C# would make XLST a very popular way of displaying object in HTML on websites?

Thanks for feeding my curiosity!!

IMHO there are two main reasons why XSLT is not very popular:

it's generally hard.
you can just skip it and directly write HTML, and HTML is not hard and has first-class support from all web frameworks.

In summary, there is usually not enough reason to introduce yet-another-abstraction. Abstractions are not free, they solve some problems but introduce others (i.e. the "solve it by adding another layer of indirection" adagio), so the benefits must clearly outweight the costs.

That said, there are XSLT-based solutions for many web frameworks, e.g.:

ASP.NET MVC XSLT view engine
libxslt in RoR

Here's an excellent article that discusses XSLT for view engines.

As I've started so many answers on Stackoverflow, it depends :)

Doing what you're describing is adding another layer of abstraction between application logic and the display output; and introducing another language. There can be very compelling reasons to do this, but the important part to keep in mind is that you need to recognize and quantify the need to be able to understand whether it's worth it.

It seems that being able to easily...

As with most things in software development, something that seems easy after a few hours of pondering turns out to be quite complex and involved when you actually try to do it. This is especially true here, because I have built exactly what you're describing in ASP.NET. It provides a very interesting mechanism for skinning sites, as you simply have to define your model XML schemas and anyone can write an XSLT to transform it. But XSLT is like a one-way tunnel. It can't (easily) reach back out or to the sides to pull in extra info that wasn't included in the original model - "peripheral data", so to speak. In fact, it has a hard time really being aware of what's going on in the application at all.

Also, XSLT is very verbose, and (in many ways) a crude language. This makes it... unpleasant to do things like loops, and rather time consuming to even do something like an if-else statement*. An XSLT that generated something like, say, the page you're looking out right now would probably be several thousand lines long - which you're adding on top of the application code you have to write either way.

It is simply an additional cost which may or may not be worth it, depending on what you're trying to accomplish.

*For example, I once saw a developer try to write a pager control (e.g. "first | prev | 1 | 2 | 3 | next | last") in XSLT. We still visit her in the sanitarium from time to time.

XSLT is not popular in web frameworks because XML is not popular in web frameworks. But, if you have XML data, or you are willing to convert your objects to XML then XSLT is the best tool for transforming that XML into HTML or XHTML.

If you are using ASP.NET checkout myxsl

When I first discovered XSLT I was excited because I could write semantically correct presentation markup, and I would no longer have to write so many hacks and use so many nested layers of <divs> just to get the effect I wanted -- XSLT could do all that for me!

Then I realized XSLT was a weird, backwards, and painful language to write in. I believe other web developers have discovered the same thing and steered away from it.

What's the point when you can just write straight HTML and avoid an extra layer of abstraction? And if your application is complex enough to warrant that, then there are so many better, simpler, more powerful alternatives (other templating languages).

The design of a web page is often handed over to designers.

One thing about web designers is they know HTML (if you're lucky) but they're not going to know XSLT.

It's unpleasant to do loops and if-else-statements in XSLT like it's unpleasant to hammer with a screwdriver. Don't do that. The behaviour of an XSLT script is driven by the data, you only need to find the right matches for your templates. XSLT-templates are not just a piece of code. The actual data from the XML-file fitting in the "match"-attribute of the "template"-elements decide if and when to execute a template.
Once you discover that XSLT works different to other languages you see the possibilities this gives to you. It's easy to do things that are hard to do in usual languages. Just use it when appropriate. If your data comes as XML and you know XSLT and XPath, this is the right tool to build web pages.
Hints are available at e.g. jenitennison.com/xslt.