Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday September 01, 2005
06:36 PM

Recursive dilemmas

[ #26563 ]

We're using XSLT because we don't want our core code to have to output a bunch of different formats. With XSLT, we can output one format and allow XSLT to handle transformation of the XML to whatever output format is desired. Unfortunately, I've been using the tried and fuzzily true "hacker's learning methodology" of just using Google and books to apply a solution to a problem as it arises.

A couple of times this has led to me discovering that an applied solution was not the best solution -- just as novices learn with any language they stick with. So do I take the time to really learn XSLT or do I just finish up the task at hand and hope that I've learned enough to just Get Things Done? In other words, I face a recursive dilemma: I need to learn enough XSLT to determine if it's worthwhile to learn enough XSLT.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I bounced off of several XSLT books until a friend suggested "XSLT for Dummies", which actually does a credible job of explaining how the damn thing works.
    • I've looked at a few XSLT books around the office, but the one that worked best for me were the two reference chapters in XML in a Nutshell [oreilly.com]. They contain just enough information to find out what you actually need to know or perhaps guess what you're trying to do.

      -Dom

      • I second that. My few hacks using XSLT were done with XML in a Nutshell before me.

        But I think that if I had to use it in anger then I would take a course, or find a tutorial at some conference - for me that is the best way of grogging the mindset of a new area. That is to have someone in the know explain it. and then read the books to get to know it. YMMV.

  • If you see yourself using XML to any extent, I recommend sticking with it. The language is actually very simple, it just has a very uncommon and less than obvious operational model that makes it kind of hard to approach.

    I fumbled for a long time before the lightbulb lit up, but I can now say it’s really a fun language (save for the gymnastics due to being expressed in XML), and most everything I conceive of works correctly right away. So if twiddling trees sounds at all like fun, you will probably

  • XSLT is certainly worth the time to learn. A few things to keep in mind though:
    • XSLT is really just Scheme with angle brackets. Get your Scheme hat on before you do anything serious.
    • Most of your work is done with XPath. If you're punting to named templates too often, rethink what you're doing before continuing.
    • With XSLT 1.0, the big bummer is that the RTF and Input are disjoint. For complex transformations, you will have to jump through hoops to gather all of the input nodes you need before transform
    • It is not too surprising that XSLT is like Scheme. It grew out of DSSSL, the SGML stylesheet language, which was based on Scheme. I have heard XSLT described as a functional language for manipulating trees.