Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Going from Perl to XSL? 52

Posted by Cliff from the my-wrists-hurt-just-thinking-about-this dept.
linderdm queries: "I am a perl web programmer who has taken a new job that requires me to do web 'programming' using XML, XSL, and Oracle XSQL. My minor experience with XSL so far has been horrible! It is so hard to do things that were very easy in Perl (looping!?!) and just seems incredibly verbose. I am curious to find out what the Slashdot community's experience has been with web programming in procedural languages (Perl, Java, etc) then switching to tag based XML/XSL. Am I wrong to be trying to do procedural programming with XSL?"
This discussion has been archived. No new comments can be posted.

Going from Perl to XSL? More

Going from Perl to XSL?

Comments Filter:

  • XML is not a programming language (Score:5, Informative)

    by Gaijin42 ( 317411 ) on Wednesday April 24, 2002 @04:58PM (#3404389)
    It is important to remember that XML is not a programming language, it is a data format. XSL is also not a procedural language, it is a language for formatting data into a stylesheet. I refer you to the XSL page [w3.org] of the w3 :

    XSL is a language for expressing stylesheets. It consists of three parts: XSL Transformations (XSLT): a language for transforming XML documents, the XML Path Language (XPath), an expression language used by XSLT to access or refer to parts of an XML document. (XPath is also used by the XML Linking specification). The third part is XSL Formatting Objects: an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary. For a more detailed explanation of how XSL works, see the What Is XSL page.

    So the short answer to your question is : no, XSL is not the right choice to do procedural logic. If you are doing something with your data other than displaying/formatting it, use something other than XSL. (Perl, Python, JSP, ASP, etc)

    • Re:XML is not a programming language (Score:5, Interesting)

      by tenman ( 247215 ) <`moc.iausten' `ta' `gro.todhsals'> on Wednesday April 24, 2002 @05:09PM (#3404502) Journal
      Right On!!! I'm so glad to see this right off the bat. Just because you don't know how to use a language doesn't mean it sucks. I have spent the last 2 years working on XML 'based' applications. The parser and the standards are what is so cool about it. The /. group should absolutely fall in love with this. It is open, and powerful, it's open, and open. What more could you want from a data storage standard?

      Like the parent poster said, you don't program loops with XML or XSL, you use something like XPATH in conjunction with PERL to do that. I have to agree that Oracle's XML stuff is not the coolest in the world (or anywhere else for that matter), but don't knock XML. XML is your friend, and you need to learn how to use it before you bash it.

      </soapbox> ha! "soap" </pun>

      • Re:XML is not a programming language (Score:4, Funny)

        by dimator ( 71399 ) on Wednesday April 24, 2002 @05:13PM (#3404533) Homepage Journal
        It is open, and powerful, it's open, and open.

        That's all well and good, but is it open ?

      • What more could you want from a data storage standard?

        Efficiency. XML is essentially uglified, hard-parse S-expressions. Think how much nicer this:

        (html (head (title "A page") (meta "keywords" "stuff")) (body #:bgcolor "#ffffff" (h1 "Title" (p "And here we have some text" (h2 "A Section" (p "And even more text")))))

        is than the equivalent. And it gets worse and worse as more data is involved.

        • 1 == 1
          and
          ( ==
          and
          ) ==

          You still have to bust out what you are looking for and compaire it in context to what is around it. symantics is all you changed.

          Look for 1st (
          Look for last )
          repeat inwards recursivly...

          same thing. goodbye.

          • 1 == 1
            and
            ( == <>
            and
            ) == </>
          • No--it's actually slightly different. (something ...) == <something>...<something>. The first is easier to write a parser for and much more elegant, to boot.
            • elegance is in the eye of the beholder, and I guess if you write the parser, you write the rules. However, the topic here is XML. A ton of rules are already in place. Parsers have already been written. If you think you can write a better one, then there is money in it for ya. '(' and ')' are cute, but you will still have to deal with the same short comings of EVERY OTHER set of parse rules. The only thing you gain/lose is key strokes. And the benefit of machine and human readable code far outways one persons bitching about his fingers. poor you....

    • Nobody said XML *was* a PL -- we're talking XSLT. (Score:4, Informative)

      by fm6 ( 162816 ) on Thursday April 25, 2002 @01:14AM (#3407148) Homepage Journal
      So the short answer to your question is : no, XSL is not the right choice to do procedural logic.
      True, but kind of beside the point. Procedural programming is not the only way to write software, it's just the model that most programmers happen to know. Functional programming [nott.ac.uk] is probably the most important rival of procedural programming. And the functional model is rather an obvious choice for an XML transformation language like XSLT, since XML models tend to be rather recursive! Maybe serious Perl hackers are unfazed, but I find the idea of unravelling deeply-nested data-structures in Perl pretty scary.

      Functional programming requires a completely different mode of thinking than procedural programming. Anybody who understands the definition of "procedure" in ordinary English understands the procedural programming paradigm, even if they don't know the technical details. But the functional programming paradigm is a lot less commonplace, and takes some getting used to. Before tackling XSLT, it might make sense to try to pick up some fundamental FP concepts. One way to do this would be to work through the leading functional programming textbook [mit.edu]. (It says a lot about MIT that they've gone and made the entire book available online!)

      It is kind of irritating that XSLT's creators decreed that a syntactically correct XSLT program had to be a well-formed XML document -- and thus rather verbose. But that sort of thing rather goes with the FP mindset -- FP source is supposed to be easily transformable using the same language it's written in. That's why there are Lots of Insipid Silly Parentheses -- and so few syntax rules -- in languages like Scheme.

      It's worth mentioning that Perl, though basically a procedural language, has some of the same design philosophy as the FP languages. It's easier to code a simple loop in Perl than in an FP language -- but Perl has as many ways to avoid coding a loop as any FP language!

      Also worth mentioning that XSLT and XSL are not quite the same thing. XSLT is the transformation language for XSL. It's a relatively recent invention. As originally conceived by Microsoft (yep, the evil empire was the biggest partner in drawing up the original XSL spec [w3.org]), transformation languages were a mix-and-match affair. A lot of early examples had XSL stylesheets with embedded Visual Basic code!

      Come to think of it, it wouldn't be hard to do a stylesheet language based on Perl, or to evolve a convention for embedding Perl instead of XSLT in XSL stylesheets. Now, why do you suppose nobody is working on that. Uh, that's a rhetorical/socratic question!

      • Re:Nobody said XML *was* a PL -- we're talking XSL (Score:1, Informative)

        by Anonymous Coward
        Come to think of it, it wouldn't be hard to do a stylesheet language based on Perl, or to evolve a convention for embedding Perl instead of XSLT in XSL stylesheets. Now, why do you suppose nobody is working on that. Uh, that's a rhetorical/socratic question!
        more of a moot question, really.

        http://www.xml.com/pub/a/2000/07/05/xpathscript/
        http://www.suranyami.com/XSPtutorial/

  • XSLT is not a procedural programming language. To quote the w3c, XSLT is a language for transforming XML documents into other XML documents. Sure, you might be able to use XSLT to generate HTML reports from the data generated by a query to a database storing XML, but you can't use XSLT alone to perform much other logic.

    Daniel Robins' articles were very helpful for me to understand how XSLT ties in with other systems.

    http://www-106.ibm.com/developerworks/usability/ li brary/us-gentoo/
    http://www-106.ibm.com/developer works/usability/li brary/us-gent/
    http://www-106.ibm.com/developerwo rks/usability/li brary/us-gentoo3/
    http://www-106.ibm.com/develope rworks/usability/li brary/us-gentoo4/

  • I've only played with XSLT but from what I've seen it helps if you can think in a functional mindset (e.g. do loops via recursion). This can be quite nice when dealing with things that have to be opened and closed like tags because you think about everything as nesting...

  • What about python? (Score:3, Insightful)

    by costas ( 38724 ) on Wednesday April 24, 2002 @05:00PM (#3404407) Homepage
    I co-wrote a small XML->Python de-serializer. Go to gnosis.cx and look around for "XML Tools". XML Objectify does exactly what you're looking for: grabs an XML file and gives you a clean object that you can loop through, attach methods to, etc, at SAX speeds. I don't know if it's doable in Perl, but probably if you mix enough $@->$_ in there it could be done :-) (couldn't resist...)

    • Re:What about python? (Score:3, Interesting)

      by costas ( 38724 )
      Let me make the above clearer: Say you have a document, with a root tag "collection", containing several "book" tags (I am too lazy to insert angle brackets here). XML Objectify will allow you for example to create an XO_Book class that will be automatically instantiated for each "book" tag in your document. It will also instantiate an XO_Collection class that you may also overload (or not).

      For example, say that you want to have a method, file(), attached to each book. You can create that method (in Python), attach it to the XO_Book class and then run your XML file through XML Objectify. You will get back an object containing the root of the XML file and objects for each tag encountered within. If there are multiple tags, you get a magical iterator. So, my example above will look like this:

      collection = xml_objectify.xml_objectify(myxmlfile)
      for book in collection.book:
      book.file()

      Procedural and OOP power, while still talking to XML. Combine that with a good template engine (Cheetah for Python is very nice) and you will hit the ground running really fast w/o XSLT.

    • Re:What about python? (Score:3, Informative)

      by Matts ( 1628 )
      XML::Parser's Object style does exactly this, and has done so for I think a couple of years now.

      But it doesn't really answer this guy's question ;-)

  • Yes. (Score:3, Informative)

    by pb ( 1020 ) on Wednesday April 24, 2002 @05:01PM (#3404418)
    http://www.dpawson.co.uk/xsl/sect2/N5019.html

    It doesn't want to be a programming language. :)

  • Going from Perl to XSL... (Score:5, Informative)

    by sab39 ( 10510 ) on Wednesday April 24, 2002 @05:08PM (#3404493) Homepage
    Going from Perl to XSL is like going from Water to Potatoes.

    They solve different problems.

    As a programmer, your toolset should include more than one tool. Perl simply cannot be beaten for text processing. XSL is probably the best out there for processing XML into other XML, but this space is immature so be on the lookout for better solutions. Java (and C#) is great for building large enterprise applications or applications that benefit from a lot of object-orientation. C is good for programming close to the metal. Python is excellent for development speed, prototyping, and general-purpose code. Fortran is still among the best out there for heavy-duty numerical programming. Prolog rules for AI. Functional languages are great for solving complex algorithmic problems. Basic is good for, well, nothing ;)

    Learn as many different languages as you can find. Then use the right tool for the job. If you find yourself worrying that a particular thing you need to do is hard in the language you're using, you're either taking the wrong approach to the problem (I believe XSLT allows some kinds of problems to be solved *without* looping even where they'd require looping in Perl) or you're using the wrong tool.

    Note: I can't say I've met all these requirements myself. My own programming experience is conspicuously missing Lisp, Scheme, Fortran and XSLT, and I only learnt one semester's worth of Prolog and never used it since; ditto ML which is the only functional language I know. And I haven't gotten as far into Python as I'd like.

    But I do know enough of each to know when I'm faced with a problem that one of them might be best for.
    • Bullshit. Basic is obviously completely optimised for writing AD&D Character Generators on the Apple ][e platform. I mean, duh, you didn't know that? ;)

      -Omar@poke

    • Learn as many different languages as you can find. Then use the right tool for the job.

      this is your best point... the tool analogy is perfect...
      screwdriver for screws, nailgun for nails...
      same thing with languages...

  • Don't think procedural (Score:4, Informative)

    by Anonymous Coward on Wednesday April 24, 2002 @05:17PM (#3404581)
    XSL is a transformation language. Don't think in loops, think in templates.
    I see horrible XSLT work where people try to use evil for-each constructions...

    And the fact that XSL is an XML application ('tag-based' as you call it) has nothing to do with it being procedural or nonprocedural, it's just a syntax issue (which can annoye me when writing more complex transformations, I think we will see more powerfull transformation languages like stratego [stratego-language.org] in the future).

  • Using Perl With XSLT (Score:3, Informative)

    by Enoch ( 86158 ) on Wednesday April 24, 2002 @05:57PM (#3404978) Homepage
    Check out this [perl.com] article on perl.com [perl.com] describing how to use Apache/mod_perl to drive a "data driven processing pipeline" through XSLT. (It is a follow-up to this [perl.com] article introducing AxKit, which is a document server.

    Jeremy

  • Parsing XML (Score:2, Informative)

    by klui ( 457783 )
    I've had good luck with using XMLsoft [xmlsoft.org]'s XML parser using the traditional C interface. The website provides both DOM and SAX paradigms. You'd use DOM if you want to read the entire XML file into memory into a tree structure and grab various XPATHs; use SAX if you're only interested in a small subset of the XML file. A DOM/XSLT processor is provided so all you need is to write your XSLT templates.

    SAX just provides the hooks that tells you whether you're at the beginning, end, of a tag, document, characters, and so forth but doesn't allow you to reference items you've already looked at--that's your program's job. It's more efficient and faster than DOM in this sense; however as your needs of the total XPATHs of your document approaches its entirety, the time saved using SAX will diminish towards the performance of DOM so you're better off using DOM/XSLT since the maintenance is easier.

    Performance wise, I found the XMLsoft version to be 2X, more or less, than that of a parser written in Java using Oracle's XML library depending on the size of the XML document. There are some features missing in XMLsoft's version but it is constantly being updated and feature gaps eliminated.

    Do a google search for XSLT FAQ for more info on DOM/XSLT. XSLT is quite a beast.

  • XSLT is Turing Complete (Score:3, Informative)

    by kgp ( 172015 ) on Wednesday April 24, 2002 @06:01PM (#3405013)
    Shocking as it may seem XSLT is Turing complete and you can code in it (not that that is a good idea of course)

    http://www.unidex.com/turing/utm.htm

    and

    http://xml.coverpages.org/ni2001-03-19-b.html

  • Don't do it. (Score:3, Insightful)

    by Apuleius ( 6901 ) on Wednesday April 24, 2002 @06:36PM (#3405363) Journal
    And here is why. [kuro5hin.org]
    ANd that's just one example.

    • Re:Don't do it. (Score:2, Informative)

      by Anonymous Coward
      Just to be clear, that article goes on one assumption that once disproven would remove the teeth and conclusions leaving a description of what the language can do and what it can't.

      It goes on the assumption that you are supposed to be able to do everything from within XSLT. This is incorrect. XSLT is for transforming one XML document into another. To do anything more complex is supposed to require another language. Maybe they'll change this in future versions, but for now there's a defined scope of what XSLT should and shouldn't do.

      So XSLT outputs XML, but saying that it outputs XML is far too vague a term. XSLT can output XML styled XML - not everything that happens to be well-formed XML. By XML styled XML I mean syntax that doesn't invent it's own way of escaping characters (ie, Javascript's backslash) rather than using the XML way. This also means outputing XML that doesn't heavily rely on CDATA. This means that the input/output files must not only be well-formed XML - but the input/output must be useful when they provide XML that takes full advantage of the XML syntax.

      Knowing this it's easy to see where XSLT suits and doesn't. It doesn't suit outputting XHTML with javascript that requires a backslash before certain reserved characters. Nor does it suit outputing in LaTeX. Nor does it suit outputing CSS.

      You may well be able to bend XSLT to fit, but you'd be better to save yourself the trouble and just push the output through something more suited to the job. XSLT isn't a general purpose text mangler - that's what Perl is for.

      XSLT is however the best way of mangling XML documents into different formats. It's syntax - although verbose - is surprisingly small and efficient when you know how to craft an XPATH.

      I've been writing XSLT for a year now, and at the ripe old age of 23, I get all the chicks - believe me.

  • Think functional, not procedural (Score:4, Insightful)

    by colin_zr ( 540279 ) on Wednesday April 24, 2002 @08:35PM (#3405880) Homepage
    Am I wrong to be trying to do procedural programming with XSL?

    Yes.

    I get the impression that you're not familiar with the functional programming style. Functional programming is a style in which the entire program is defined as a function. There are a number of languages which support functional programming. (Lisp and Haskell are probably the most famous, but XSLT is a functional language as well.) I'm not going to explain the entire theory behind functional programming at this stage. I'll just say that if you wan to be able to use XSLT as anything more than a glorified template system, you'll have to learn about functional programming.

    You ask where looping is in XSLT. Well, functional languages tend not to do looping. You have to do it all using recursion.

    If all you've done is procedural programming then it will seem very weird for a while. It takes some time to get good at it. I experienced a period of frustration when I first started with XSLT, but once you realise that it's functional, it suddenly becomes quite a powerful language.

  • zvon.org (Score:2, Informative)

    by Anonymous Coward
    I find zvon.org [zvon.org] to be a great site for understanding w3 standards (including XSLT). The tutorials are just sequences of examples; they get straight to the point.

  • XML folks believing their own hype (Score:3, Insightful)

    by pong ( 18266 ) on Thursday April 25, 2002 @03:00AM (#3407504) Homepage
    XML is a useful technology - very useful, and simple too. That does not mean that it is right for every purpose, though. The XML folks, believing their own hype, simply forgot that and decided that the syntax for XSLT should be XML-based. Bad Idea! Use XML for communication between machines, not for machine - human communication! While made to be readable for people, it is verbose and there is waaay to much line noise.

    It's like that everytime something is hyped - people will use technology where it just doesn't make any sense.

    • Granted, defining a language or technology to be syntactically based on xml makes it very verbose, but there are other consequences of this too.

      For one, this allows for facilitated tool integration and automated manipulation and handling. This could be for a graphical or more concise textual represenation of the xslt "program" or for automated generation. And tool integration should not be underestimated.

      Think of the refactoring support that editors/IDEs are starting to provide. AFAIK, Right now this is most prevelent in java environments (have a look at IntelliJ's iDEA [intellij.com]), having its origins in SmallTalk. This will probably be extened to other languages and technologies over the next one to three years.

      I highly recommend the book Refactoring: Improving the Design of Existing Code by Martin Fowler. Also checkout the site refactoring.com [refactoring.com].

  • Use extensions (Score:2, Informative)

    by havardw ( 180104 )
    I've used extensions for some of the things that I couldn't easily do in XSL.
    Takle a look at the Xalan extensions [apache.org], or find something for your implementation.

  • You must learn about functional languages (Score:3, Informative)

    by aburnsio.com ( 213397 ) on Thursday April 25, 2002 @10:56AM (#3409080)
    I wrote this big long post about language paradigms but my browser erased it. Thank you, IE.

    Anyhow, what you've got to get through your mind is that XSLT is a functional language; it's not procedural. We're not in Kansas anymore, Toto. Functional languages are a different beast than what you're used to, i.e. procedural languages.

    If you've taken a CS course on programming languages and they covered functional languages well than you don't have to learn anything, just realize that XSLT is functional and program accordingly.

    If you haven't taken a CS programming languages course or didn't cover functional languages then you need to learn the functional paradigm. Think transformation, not variable assignment. Think functional composition, not a row of statements. Think recursion, not looping.

    To learn it yourself, you're going to need a good book on functional programming, such as Haskell [bookpool.com] or Erlang [bookpool.com]. Both have open-source implementations available. This is not something you're going to learn in a day, it will take you a month of diligent study before you understand what you're doing. If you know rigorous logic well and are adept in discrete math and set theory you'll advance more readily.

    In addition to learning functional programming, you'll have to learn the quirks of XSLT. For one, you need to have mastery of the specs for XML [w3.org], XPath [w3.org], and of course XSLT [w3.org]. Al these specs are quite readable: read them through, try out examples. You also need to be aware of the limitation of XSLT, especially in these early days of the 1.0 version (2.0 should be more useful). Often you'll need to either do processing before/after XSLT with Perl or something else, or directly incorporate JavaScript into your XSLT document. Be sure to understand inclusions and use XSLT library documents with useful functions.

    Once you understand functional languages in general and XSLT in particular you'll be on your way to mastery of XSLT. You'll also learn alot along the way that will be useful even if you never touch XSLT again. In addition, you'll have experience in the maxim uttered by other posters that you must use the right tool for the right job. XSLT is superb for most common XML transformations (such as XML to HTML) and is far better than any other languages for doing this. But sometimes you need something else like Perl or Java for direct manipulation. Use the right tool for the right job.

  • That is, it is a powerful functional language which gives great control over XML data. I contend that, if you do it right, your XSL code will be cleaner, easier to maintain, and faster than the same written in Perl.For one thing, XSLT *forces* you to output well-formed HTML (or XHTML). Perl will let you write whatever you want. Second, although it is a "functional" language, it has borrowed features from OO languages like C++. For example, one can "override" templates with custom implementations.

  • XSL Considered Harmful (Score:3, Insightful)

    by Voivod ( 27332 ) <cryptic.gmail@com> on Thursday April 25, 2002 @05:53PM (#3412137)

    Check out this excellent article entitled XSL Considered Harmful [xml.com] by Michael Leventhal from 1999. IMHO it's as true now as it was then.

  • Not just Functional (Score:3, Insightful)

    by bevan.arps ( 78909 ) on Friday April 26, 2002 @06:13AM (#3414807) Homepage
    A number of posters have already pointed out that XSLT isn't a procedural language, so procedural thinking won't be the best approach.

    However, XSLT isn't just functional (although functional it is). It can also be characterised as a rule based language.

    A match template can be viewed as a rule that defines what actions should be taken in particular circumstances.

    As an example, loops often don't need to be explicitly coded at all. Instead of writing some code to say "Find all elements and iterate overthem doing Xyz", you just write a template that says "Whenever you find an do Xyz" and let the stylesheet processor drive things for you.

    I'd suggest that the last thing you want to do when writing XSLT code is to think with a Perl mindset (insert procedural language of choice instead of Perl - Java, Delphi, C, C++, whatever).

    Instead, concentrate on thinking about the facilities the language does provide. Buy yourself a good book or two - Micheal Kay's "XSLT Programmers Reference" is very good. I keep my copy within arms reach whenever doing something tricky.

    Every language has its very own mind set - or paradigm, if you will. Even between languages that have substantially similar capabilities (eg Java and Delphi), the "most right" way of solving a problem can be very different, simply because of the design paradigm the language and library designers used.

    XSLT is no different - and because the language is so different to conventional procedural programming languages, you'll tie yourself into great knots if you don't put some effort into learning the "XSLT Way".

    A couple of final tips ...

    ... XPath is your friend - learn about paths and predicates.

    ... Do pay attention to modes (see xsl:template and xsl:apply-templates)

    ... do search the web and pull apart stylesheets written by others

    Hope this helps.

  • Keep it small! (Score:3, Informative)

    by hoquaim ( 169689 ) on Saturday April 27, 2002 @11:56PM (#3423285)
    I've written many thousands of lines of XSLT code. I've grown to really despise XSLT, and I'll offer these cautionary notes... The more logic you have to write, the more you need to think about your use of XSLT. I've found that it's very easy to write hard-to-maintain code in XSLT.

    I've also have had to resort to extensions (written in Java) in a number of cases. Not only was this a pain, but it made my XSLT non-portable between Apache's Xalan and Saxon (let alone non-Java processors).

    XSLT is great for small XML transformations (and perhaps especially good for HTML generation -- that's NOT what I was doing) -- where small is referring to the number of XSL templates, and the line count of those templates.

    Also: a number of people have mentioned the functional nature of XSLT. It also has many declarative aspects: in particular many of your templates are not explicitly called by name, they are implicitly called by rule matching in the template definition. This is one of the aspects of the language that makes building large applications in XSLT difficult (and yet for small scripts this same feature is powerful!).

    The greater your ratio between logic : emitted-fragments (ie. HTML), the more caution you need to use with XSLT (and the greater the likelihood your app is better implemented in a language good XML support, Java, C#, Perl, Python).

    Finally, I wrote a ~500 line XSLT script and the equivalent transformation in Tcl (+TclDOM). XSLT with Saxon or Xerces took about 3 or 4 seconds to run, Tcl took about 200 milliseconds! So: be aware of the performance aspects of your XSLT engine.

    Now that JDOM (an XML API for Java) has XPath support, I'll be far more likely to use Java for many of my XML transformation needs. The coolest thing about XSLT was the fact that it had XPath... now many traditional scripting and OO languages have XPath support which greatly eases XML processing in those languages (much the same way that adding regexp support to a language makes string processing much easier).
  • it's actually Prolog in different syntax.
    I love prolog and was really pleased to see its incarnation in XSLT.
    You have to change your style of thinking to write good programs on declarative languages, so it's why you are so in trouble while using XSLT.
  • I have written web application using Perl and XSLT (and a few other technologies). The biggest issue with XSLT using XSL files as the templates and XML as the data (how else would you do it ;-)) is that XSLT is meant to recurse over XML DOM objects translating the values of the DOM objects into another DOM (HTML in this case). Most web developers want (rightly so) to just use simple replacement variables and do string replacement in very limited places on a template.

    Perl is great for doing this kind of template based approach, so is PHP and Cold Fusion and other programming environments. XSL files and the XSLT process are fairly heavy weight for a simple find and replace the 75% of web applications want. Originally XSLT was meant to be an off-line process, i.e. not on the fly, where the extra flexibility but heavy weight process was a plus, not a minus. But this idea of the right tool for the right job is lost on most people.

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close