in reply to Re: Re: Re: HTML::Template - what's the rule of thumb?
in thread HTML::Template - what's the rule of thumb?

Still I think in the long run, templating systems are a dead branch of the evolutionary tree: they are neither pure programs, nor pure mark-up but a hybrid of the two, which IMHO combine the bad things of both for little benefit.
I'll disagree, on two levels.

One, in order to get a file that is "pure markup", you have to have some logic to generate that file. Parts of that logic will have static text, and parts must have enough dynamic logic (decision/iteration/subroutines) to be turing complete. That's actually a perfect place for a templating system!

Two, if you follow the MVC paradigm, your View usually ends up having to adapt to display the Model being tossed at it by the Controller. A good templating system has at least enough stuff to do that, although it doesn't need (or want) to have enough stuff to be the Controller itself. I think the failure of some templating systems is their attempt to be used as Model or Controller code.

An example of a failure of "pure markup" is XSLT. You end up twisting yourself around corners just to write programs in what tries to be a pure mark-up language. Feh.

If you think templating systems are a dead-end, you should probably describe what you would replace them with. It's also possible that you have a narrow application domain that you're specifically addressing. It'd be nice for us to know your scope of statement.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

  • Comment on •Re: Re: Re: Re: HTML::Template - what's the rule of thumb?

Replies are listed 'Best First'.
Re: •Re: Re: Re: Re: HTML::Template - what's the rule of thumb?
by CountZero (Bishop) on Dec 21, 2003 at 10:41 UTC
    I run an intranet site which gets data on marine claims out of a database. The various perl scripts generate XML output which are then transformed by XSLT into pure HTML (and CSS provides for the standard look as per our corporation's "look and feel" guidelines).I run one large XSLT file for all the webpages and if something global needs to be changed I do it in one place and everything follows.

    Recently a customer requested that certain columns on the webpages needed to be summed. This only was a small change in the XSLT and nothing had to be changed in the scripts. Now you probably are going to say that you could just as easily have amended the template (but probably many different templates needed to be adapted) and you are probably right. But XSLT has a lot more possibilities than any templating system. In that, it is less (or even not at all) a mark-up language (certainly not a pure mark-up language) than a programming language in its own right.

    Yes it means you have to learn an extra language, but I happen to like it and it provides nice buzzwords to pacify the PHB!

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
      But XSLT has a lot more possibilities than any templating system.
      You had me up to here. Then I lost you, because you never justify it, and this is the point we differ on.

      A "templating system" like Template Toolkit has all of Perl to escape to, without shifting gears. To extend XSLT, you have to code in some non-XSLT language. This implies the opposite of your statement.

      What axis of interest are you looking at to say what you said?

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]
        You are quite right Merlyn, I did not make myself entirely clear. (make note to /me : never start discussing with Merlyn in the morning unless you have at least had your second cup of strong tea)

        The trouble I have with templates is indeed that you can (and many times have) to fall back to Perl (or whatever language is supported in the templating system), which defeats the purpose of making a clean split between logic and layout.

        To get the data out the database, I rely on my good, old and trusted Perl-scripts. This is the "logic" part. Once the data is in XML-format, I hand it to the XSLT-script which does all the nice formatting (putting it in tables, adding headers and footers, coding the links, calculating sums and percentages, even providing the parameters to the GD-script for making the charts). Thanks to the filtering capacities of XSLT and XPath, the same XML-data can be used to present different views or extract different type of data.

        I find that I rarely have to amend the basic Perl-scripts and that most of the work can be done in the XSLT-file.

        DTD or Schema describes the XML-data, so (theoretically) anyone who knows DTD/Schema and XSLT can work with the data my scripts provide. Practically I'm the only one who does, so I could have put everything in one big Perl-script with tons of print statements and heredocs.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
      I think you're missing the point of a templating system. It has nothing to do with making sure that your display logic doesn't have any programming stuff in it. In fact, I am switching from HTML::Template to Template Toolkit precisely because it has better programming stuff in it.

      Within MVC (which it seems you do use - good for you!), you will have three programming layers, hopefully separated by rather strict APIs. Each of the layers, most likely, will have a ton of programming in them, and that's ok. Very often, one cannot convert a data structure into something to be displayed without it.

      The notion that templating systems should be as dumb is possible is a mis-meme, promulgated by the facts that

      • HTML::Template is the most popular templating system in Perl, even though
        • it's only a stripped-down version of the first version of Template Toolkit
        • it was never meant to be a complete templating system
      • Most programmers think that designers make for poor programmers
      • Most programmers make for poor designers

      Yes, good display logic is expensive. Sometimes, the only way to do something is to drop into a full-featured language. So?

      Remember something - a popular templating system for Windows programs written in Visual C++ is Visual Basic.

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
        My oh my, old sins do get visited upon us in eternity!

        dragonchild, I must confess that for the second version of my intranet claims system, I have switched to Template::Toolkit, but it still outputs XML and this XML still gets tranformed into HTML through the services of XSLT and CSS.

        The reason I (finally) switched to a templating system was that is allowed me to write more "condensed" code, i.e. lots of back-ground functions get "glossed over" by using the template-constructs (such as connecting to the database; managing arrays and hashes; ...).

        I'm still not entirely happy with the ideas behind templating systems,nor with the practical implementations, but untill I have lots of free time and start writing it myself, I will have to use and make-do with what exists! That being said Template::Toolkit is certainly one of the better templating systems around.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]

In Section Seekers of Perl Wisdom