Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re: Model-View-Controller: Template Toolkit vs. XSLT

by Matts (Deacon)
on Oct 16, 2004 at 21:16 UTC ( [id://399822] : note . print w/replies, xml ) Need Help??

in reply to Model-View-Controller: Template Toolkit vs. XSLT

You'll hear a lot of bad stuff about XSLT from Perl programmers. There are two reasons for this:

a) They are perl programmers not XSLT "programmers".
b) Perl geeks don't like XML.

Believe some of the hype, not all of it. And believe some of the bad stuff, not all of it.

I've created some very large projects using XSLT and AxKit, and while XSLT isn't the easiest thing in the world, it does have some nice features, such as being declarative (something almost no other perl templating solution achieves well) and being nicely standardised.

There are some comments about non-portability of stylesheets between processors, but assuming you don't use "extensions" then this does not bear out in the real world - stylesheets port very well between platforms.

In closing, my personal opinion is that TT is nice, but is much more of a programming language than XSLT is (despite XSLT offering functions and variables). XSLT is more likely to be understood by future "Design Geeks".

Replies are listed 'Best First'.
Re^2: Model-View-Controller: Template Toolkit vs. XSLT
by drfrog (Deacon) on Oct 20, 2004 at 02:13 UTC
    templating systems will never be better than XSLT's for a couple of reasons

    it all has to do with language, encoding and xslt scripting /xpath

    one of my previous jobs was to make a xml engine for a cell phone game company so the game data could be passed as xml into the engine and translated for the various wap browsers out there.

    not only were there xslt's for the phone layout but for the different browser inconsistencies {you think web browsers are bad lol riiight} as well as for different language support {i remember kanji giving us a bit of trouble in this department, but just changing the laguage in the xml header fixed this iirc}

    by using xslt includes and imports we were able to eleviate a lot of the programming

    sure i love html::template , but it has limitations, and if i needed to provide an industrial strength application i would go xslt's
      templating systems will never be better than XSLT

      Never? You can't think of any situation where XSLT isn't the right tool for the job?

      it all has to do with language, encoding and xslt scripting /xpath

      I don't know exactly what you mean here, but Template::Plugin::XML::LibXML and Template::Plugin::XSLT have been mentioned earlier in this discussion, demonstrating that XPath works in non-XSLT environments. Which language and encoding issues does XSLT deal with better than all other templating systems? The latest version of Template Toolkit (2.14) offers improved Unicode support.

      I think the point you make with mobile phones is that XSLT can run on the client side, whereas other templating tools can't. I agree this can help in certain situations, but often I prefer to keep the client side as simple as possible, doing complex work on the server environment. As you mention, client side environments differ considerably in their treatment of the same information.

        never is strong sure, but i already stated i still use html::template as well.. the distinction is in how elegant/elaborate your system must be.

        html::template is great for simple things but it runs outta room pretty fast, IMO

        nothing in my scenario was run on the client side, but the language and encoding issues I talked about were on the client hardware...aka cell phone

        see with cell phones encoding and languages {english vs japanese ...not perl vs java} are very important, and particular.. with xslt's it was very simple to change the encoding and language types at the top of the file and watch it propagate across the application