in reply to RFC: Templating without a System

don't have a chance at the moment to review in full, but a few phrases in your intro caught my attention:
Template::Toolkt has an own mini-language, hmm.
 The Template::Toolkit language is pretty easy to pick up (and decent docs at http://template-toolkit.org). Also, you can ember striaght perl with the [% PERL %]...[% END %] directive (see "Directives" section of the Manual).
Mason works with non- standard <% %> tags. Ah well.
 I assume you can configure those (you can in TT), though i don't know offhand..

Seems like TT covers your 5 pts.. but if you're under such a time crunch, you're pretty much forced to go w/whatever works best (read:fastest) for you, which is probably your custom-tailored solution..

Replies are listed 'Best First'.
Re^2: RFC: Templating without a System
by shmem (Chancellor) on Jun 17, 2006 at 14:47 UTC

    The Template::Toolkit language is pretty easy to pick up

    I just see no sense in introducing a mini-language for templates. Perl has all things necessary ready for that, and with use strict you're on the safe side. Mini-languages just introduce an abstraction and ask you to believe they are reliably coded. TT claims to "Do The Right Thing" with its glob-like variables. How can I know?

    Seems like TT covers your 5 pts.. but if you're under such a time crunch, you're pretty much forced to go w/whatever works best (read:fastest) for you, which is probably your custom-tailored solution..
    The point is, every templating system covers the 5 points, but it's about templating - with no system - in the most standard perl way possible.

    greetings,
    --shmen
[reply]
[d/l]
      It makes very little sense to introduce a mini-language if your primary HTML-whackers are also already Perl coders.

      However, in many jobs shops, the HTML-whacking is done by people who specialize in that, and are generally better at driving DreamWeaver and Photoshop than they are at driving Emacs (or even vi).

      Many people have reported that they can comfortably teach-by-example to these designers the mini-language of TT far faster than trying to explain why it's @foo in one place, but $foo[3] somewhere else.

      So, while a mini-language may not make sense for you, it makes a great deal of sense in these shops.

      Also, I find that having a mini-language keeps me honest about MVC. About the time it starts getting hard to write in TT, I realize that I'm actually writing control or model code, and that code belongs away from the view code. So, I rip that out and put it in Perl or SQL where it belongs.

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

[reply]
[d/l]
[select]

        So, while a mini-language may not make sense for you, it makes a great deal of sense in these shops.

        Ack, thanks for pointing that out. There are also those shops in which they don't want to know or do anything beyond the design and layout, and consider inserting loops or conditionals or even variable templates as being "not their job".

        Also, I find that having a mini-language keeps me honest about MVC. About the time it starts getting hard to write in TT, I realize that I'm actually writing control or model code, and that code belongs away from the view code. So, I rip that out and put it in Perl or SQL where it belongs.

        Then you are using the restrictions of the mini-language to discipline yourself? It's a good thing to put up fences which thou shalt not pass, but it's better to have them "inside".

        I love perl particularly for what is said in the perlmodlib manpage note at the end: "It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun."

        greets,
        --shmem

[reply]

In Section Meditations