http://qs321.pair.com?node_id=142130


in reply to XSLT vs Templating?

Whee - a question just made for me! ;-)

Let me start off by saying that almost everyone misses the point when it comes to XML+XSLT. Especially when it comes up against everyone's favourite tool: TT2. Passions rise, and fevers pitch.

So what is the point? Well in my opinion, the biggest point about XSLT is it's all about structures, not text. The problem is people think of XML as text, and so think inside a very limited "text" box. But really what XML is, is a fancy "dump" format for a hierarchical structure. That's why XML is so cool - because it's not about text - it's about structures.

So why does that make XSLT cool? Well because with XSLT you don't take some structure plus a template and generate some text (the TT2 model, along with every single other perl templating tool out there). You actually take a structure, plus a template, and generate a new structure! This is a whole new approach to "templating" that Perl people don't tend to be comfortable with, but really it's very very smart, and very very useful.

One of the most useful things you can do with that model is do chaining or pipelining - piping the output of one transformation into the next - like Unix pipes only better. This is one of the things AxKit implements, and is also the sheer beauty behind SAX filters that I love so much. This may sound quite inefficient, but it's really useful to develop stylesheets that do one small thing well (e.g. create a ToC from a file), and chain multiple stylesheets together, than it is to create one big monolith and debug it.

Also most of the Perl templating solutions miss out on declarative processing. XSLT implements this and does it really quite cleanly. The idea is that rather than iterate over your structure manually (foreach loop), you declare what you want to happen when the XSLT processor sees certain node types. This makes processing documents possible (as opposed to processing data, which is all perl templating solutions are really good for IMHO), and it also makes your templates nice and clean. I believe Andy was talking about adding something like this to TT2, but I'm not sure how far he got. But think though that this technology in XSLT has been in design since the mid-1980's, in DSSSL.

Another useful thing is multiple implementations. Often it's good to be able to use somebody else's XSLT engine. This goes among other comments about cross platform utility too.

Finally, another bonus is debugging. It may not seem like it now, but XSLT actually has much better debugging support than TT2, with the likes of Komodo and all the commercial players (MS, Oracle, IBM, etc) all have XSLT debuggers included in their development environments now. Hopefully we'll see more in the open source arena in terms of XSLT debugging, but I believe there's now a plugin for Emacs that can use libxslt's debugging hooks.

OK, about books... If you're hardcore, Michael Kay's "XSLT Programmer's Reference" is indispensible. But it's seriously hardcore. I have heard good things about some of the recent XSLT books, but I don't own any so I would hesitate to recommend any. I'll recommend XML in a Nutshell, but I was involved in its production (tech editor), so I'm biased.

As far as Perl XML books are concerned, I'm keeping schtum on that.

Don't be scared of the XML syntax. It takes a bit of learning, but a lot of thought has gone into XSLT over the last 20 years, and they got most things just right. It does have a steep learning curve, but it's very powerful, and there's not much it can't do.

Replies are listed 'Best First'.
Re: Re: XSLT vs Templating?
by tomhukins (Curate) on Jan 29, 2002 at 02:12 UTC

    This is also something I'm interested in - I've been talking to various people about this recently.

    Aside from the technical merits of the TT2 / XSLT approaches, there's another important issue: What skills do you have available for the project?

    My previous place of work is a typical multimedia design agency. The technical staff mostly fall into one of two categories: back-end or front-end developer. The back-end developers (like me) worked with tools like Perl, Apache, Unix, SQL databases and XML feeds. The front-end developers worked with tools like Photoshop, HTML, limited JavaScript and Flash. I was talking to one of the front-end developers the other week, and he mentioned that most of them much prefer the old HTML::Template systems I developed to the XSLT systems they're working with now. They prefer the basic syntax of HTML::Template to the more functional approach of XSLT, and they'd probably also prefer it to TT2 because of its HTML-like syntax. HTML::Template's simplicity can cause problems with more complex projects, though, so TT2 is often more appropriate, as well as being more widely used. I've heard other front-end developers mention that they like Cold Fusion for similar reasons, although CF is a back-end developer's worst nightmare...

    At my current workplace, we're using an XML/XSLT system for the rapid development of a number of similar sites. Several of our group have learnt XSLT, and I get the impression that although they've found it awkward, they like it once they're used to it. People have different skills: most developers do bits of both front-end and back-end development. Designs come from an external group, as does research and development into new tools. XSLT seems to fit well with people who are neither expert graphic designers nor software developers, but have a broad range of Web skills.

    Also, I think it's important to focus on the distinction between different uses of XML - documents and data - that Matts makes.

    In my previous job, we were using XML for newsfeeds, i.e. data. I stored the XML feeds in a SQL database, and used some Perl to interrogate the database and pass information to HTML::Template documents. Everyone involed found this clean and quick to develop, and easy to understand. If you're working with simple data, the procedural style of Perl-based templating systems is ideal; you don't need the complexity of XSLT's callouts.

    My current job is basically about delivering documents via the Web for distance learning. Using XML and XSLT for this is ideal. Given the different types of information that can appear at any point in a document, developing TT2 or HTML::Template templates would be almost impossible. XSLT gives us the flexibility to process complex documents with the same template for numerous sites, with a stylistic skin that ensures each site has its own look and feel.

    I've not read Michael Kay's book, but I get the impression from others that it's best-suited for more technically minded people. I've been reading O'Reilly's XSLT (Mastering XSL Transformations) and found it easy going, but too brief to fully explain some topics. I've found myself using parts of resources linked from W3C's XSLT site as well as Google for learning XSLT, which isn't ideal.

[reply]
Re: Re: XSLT vs Templating?
by Masem (Monsignor) on Jan 28, 2002 at 23:26 UTC
    Ok, that starts to piece together what I get out from reading J2EE journals (one recent piece talked about a series of XSLT filters to get from one transformation to another). And given that XHTML is XML-compliant, it makes sense as well.

    Now, to further clarify what I should proceed, I'm looking at basically cleaning up a site, such that I generate XML and then generate the (X)HTML from that. This is mostly for my own learning benefit, so I'm open to any route, but I'm also trying to keep it to an efficient method as well (on an older machine, too). In addition to any XML that I generate from a DB, I also want to add the standard header, footer items, handle CGI form elements, as well as implementing user-based customizations. Ideally, I'd like one single script (with multiple callouts depending on state) to do this, basically waiting from XML recieved from the callouts, then processing it in some fashion.

    It sounds like both TT2 (templates in general) and XSLT can do this, with XSLT being a tad better since I can use two transformations, one to get the XML into a form that I can then apply a user-based transformation on. But again, I'm still new to this and trying to decide which way to go from here. Any further suggestions at this point? (It should be noted this is all with perl and apache and postgres if that should matter).

    -----------------------------------------------------
    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
    "I can see my house from here!"
    It's not what you know, but knowing how to find it if you don't know that's important

[reply]
      The right way to do something is a very hard question indeed. Especially where web stuff is involved.

      You mention Apache and Perl. But are you using mod_perl? In which case AxKit might be a good bet. If not, take a look at CGI::XMLApplication, and also see Kip Hampton's recent articles on XML.com talking about that module.

      If you go the AxKit route, look into XSP, specifically AxKit::XSP::ESQL (on CPAN) for doing SQL. If you go the CGI::XMLApplication route, check out XML::Generator::DBI and XML::LibXML::SAX::Builder to build a DOM from the results, and pass it to XML::LibXSLT for transformation.

      Probably sounds like an overwhelming number of options. So let me know if you want further details!

[reply]

In Section Meditations