Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.

XSLT vs Templating?

by Masem (Monsignor)
on Jan 28, 2002 at 19:01 UTC ( [id://142061]=perlmeditation: print w/replies, xml ) Need Help??

I played around with getting XML generation from a DB and then rendering that XML in some fashion as (X)HTML. Generation the XML is typcially no problem, but I'm looking at the various choices in the presentation of XML. It looks like the most general solution here is to use XSLT stylesheets to mark up the XML into strict XHTML with help from XPath (this is the language neutral solution). However, in Perl, we have various template solutions, including Template Toolkit 2. TT2 now has an XPath extention such that you can refer easily to parts of an XML document that you pass to it, though here, the output of the templating solution may or may not be proper XHTML (depending on how well I write the template code). However, with TT2, you also get the addition of a lot of additional functionality that you may not have gotten from the various transformations allowed on the data by XSLT. It would seem to me that using TT2 for transformations also gives you more control on the rest of the layout of the page (eg using INCLUDE statements for headers, footers, etc), though I believe I saw that XSLT also had that.

Does anyone have any suggestions as to which way is better for XML->(X)HTML in perl? And as a side question, does anyone know any good books that cover XML, XSLT, and XPath (such as anything from ORA?)

Dr. Michael K. Neylon - || "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

Replies are listed 'Best First'.
Re: XSLT vs Templating?
by Matts (Deacon) on Jan 28, 2002 at 22:00 UTC
    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.

      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.

      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 - || "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

        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 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!

Re: XSLT vs Templating?
by ajt (Prior) on Jan 28, 2002 at 20:16 UTC
    Masem, Cool question ++. I'm currently using the following:
    • Xalan XSL-T engine from the Apache group, C++ version works, but the Java one doesn't like me.
    • Instant Saxon, from Micheal Kay, Java standalone job.
    • Matts excellent XML::LibXSLT along with other XML tools.

    I have found that the Perl interface in LibXML and LibXSLT are pretty powerful and fast, and seem to work okay, they can even hadle XSLT jobs that MSXML and hence XML Spy can't.

    For my sins I'm using a home grown Templating system, but I plan to migrate to AxKit, which seems to do everything I could ever want....

    On the books front, I have the following:

    Good luck whatever you do....

      I've been very impressed with Aaron Skonnard and Martin Gudgin's Essential XML Quick Reference: A Programmer's Reference to XML, XPath, XSLT, XML Schema, SOAP, and More. It's in the same style as an O'Reilly nutshell book. It's very up to date with some handy UML diagrams. The examples are in Java and Visual Basic which is interesting as you can see the same interfaces being implemented in two entirely different languages.

      Still waiting for a hardcore Perl/XML book. :-( Perl's powerful way of handling data structures make it feel to me like the perfect language for working on XML, but Java seems to be doing a very good job of selling itself as THE language for XML.

Re: XSLT vs Templating?
by ViceRaid (Chaplain) on Jan 28, 2002 at 19:56 UTC

    Interesting question. To my eyes, you've identified the main distinction when you say about XSLT that "this is the most language neutral solution". If there's a likelihood that you're going to need to move onto another platform (Java / PHP / Python / Ruby / ... whatever), and the idea of porting either TT2 functionality or TT2 templates to language x doesn't really thrill you, then it would seem that XSLT would be a good choice. You'd be able to move between platforms and languages pretty easily, without having to rewrite much of the presentation layer.

    However, having used TT2 a fair bit, and fooled around with XSLT, it did feel like XSLT was making me work pretty hard for the end result. Of course, a very large part of that is going to be due to my lack of experience with XSLT, but maybe that's not the whole reason; it seemed slightly verbose, and quite hard to debug. I'd be interested to see other monks' suggestions for some good books on this.

    If you're not likely to move platform, and the changes that are likely to happen to the site are at the level of the data you're presenting and the way it's presented, then maybe TT2 is the way to go. It does make a (fairly) clean separation of presentation, content and logic, it's quite 'Perl-ish', and I have a hunch that for a lot of tasks it's a bit easier to work with. And, as you say, you can generate strict XHTML just as easily, so long as the templates are written carefully.

Re: XSLT vs Templating?
by perrin (Chancellor) on Jan 28, 2002 at 20:05 UTC
    In addition to XPATH for TT2, I've found the XML::Simple plugin very easy to work with.

    I don't think XSLT gurantees correct XHTML anymore than TT2 does, so your decision should probably be based on ease of use and performance.

      XSLT guarantees XML, though not necessarily XHTML. TT2 doesn't guarantee anything other than "text". It also has a HTML output method, which can help with buggy browsers (read: Netscape 4), and offers some guarantees.
        I thought you could use XSLT to produce various output formats from WAP to PDF to TeX. Is that not correct?

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://142061]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2024-06-22 07:30 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.