in reply to Re: The scope of templates
in thread I need a title - sucka! :-)

The "time spent" on generation argument doesn't matter if the generation of the content takes an (or some) order of magnitude more than the generation of the markup and if the resulting content is not cacheable.

A templating system (although called Perl Preprocessor) we have, are and will be using is Text:Vpp for dynamic document generation (mainly LaTeX files).

I have some advice:

From my experience as project manager: Don't get passionate about this (advocacy). You have found a nifty tool. But don't try to apply it to solve all (templating) problems you have. For some of them it is too big, for some it is too small. I didn't say it is useless. There's a big bunch of things where it is exactly the right thing.

From my experience as computer scientist: The expressive power of a given system is of course dependant on its - well - expressiveness. I mentioned the comparison between Perl, a *real* Templating system and HD. Of course everything is possible by extension. You may include even perl-code to a template to achieve some things, but then...

...From my experience as programmer: you really have messed up your design. What you planed to achieve - separation of code and data - for better maintainability,reusability etc. gets lost.

And finally from my experience as managing director of two companies whose core products are based on Perl:

I do this for a living too. :-)

Bye
 PetaMem     All Perl:   MT, NLP, NLU

And I am very unhappy about the quality of the perl code of the OSS project we used as basis for our NLP portal.

Replies are listed 'Best First'.
3Re: The scope of templates
by jeffa (Bishop) on Nov 29, 2003 at 16:15 UTC

    Yep. We are now comparing apples and organges.

    Please allow me to start over. Here is what i am passionate about: seeing someone use HERE DOCS to create their own half-baked "templating system" for the generation of HTML documents (i never said anything about LaTeX). Why am i passionate about that? Because i have extensively used HTML::Template and Template with great success, being able to finish on time, and being left with a very, very extensible and easily modifiable system. I am also passionate about it because i have used and seen other technologies that allow you to paint yourself into the corner a few months down the road. The reason i spoke up against your original HERE DOC code is that you cannot convince me that storing HTML inside some Perl code is better than storing HTML inside it's own .html text file. Sure i have to load it into memory ... but this is WEB PROGRAMMING!!! That time is so negligable, but then again, i am not producing LaTeX (and i will probably never have to).

    Now then, i am not arguing that HERE DOCS are bad and should be deprecated, i just don't need them. If HTML::Template and/or Template (or HTML::Mason, Apache::ASP, CGI.pm) used HERE DOCS under the hood ... i would still use them! Again, my argument really is not about the technology that was chosen, but the failure to use an existing solution from CPAN.

    So, if i have a need to create LaTeX, then i will most definitely look at Text::Vpp ... and i wholeheartedly thank you for introducing me to it. But ... i do HTML and plain old text.

    Now then, a small rebutal:
    "...From my experience as programmer: you really have messed up your design. What you planed to achieve - separation of code and data - for better maintainability,reusability etc. gets lost."

    Well, exactly what have you done with HTML::Template? Until you "figure it out", you will most certainly lose your goal of content/data separation. The tool itself only lends you a hand to successful, maintainable, and reusable seperation. It's up to YOU to see that those goals are achieved. Speaking from my own experience, i failed many times, still stuck in my ways of thinking that certain bits of HTML still needed to be generated from the code. Once i learned what content/data seperation really means, my templates and code started to reflect it.

    Now then, when i said i do this for a living, i was talking about Web Application Development ... HTML. For the record, anyone who does that for a living is a fool if they think that HTML::Template and Template are just "nifty tools" - they are quickly becoming necessary tools. Even PHP (which i still use where appriopriate), a templating tool in itself, offers at least two templating tools: Smarty and a PHP HTML::Template.

    I am sorry, but your words are still those of someone who has not used these tools enough to give valid critisms ... yet! I want more proof, and not just your opinion. (And i should note that i am very skeptical about people who still use UPPER CASE letters in their HTML tags - that's a big "still stuck in the stone age" flag.)

    And finally, for the record - i do not dislike HERE DOCS. I just shouldn't have to use them directly or have to scan through them to find what i have to change. God forbid that a web developer had to do the same ... and no, CSS won't always prevent that from happening! I consider HERE DOCS to be a quick and dirty tool for those quick and dirty moments when i need some quick and dirty results. But, tell me ... what advantage does using a HERE DOC have over 

    my $header = qq|<html>
<head>
<title>$title</title>
</head>
|;

    [download]
    and how do you achieve conditional branches and loops with HERE DOCS? (And yes ... i know that Text::Vpp provides this.) You build them yourself. That is what i was arguing against, and the fact that you just admitted you use an existing CPAN module to "manage" your HERE DOCS only strengthens the spirit of my argument: USE THE CPAN! ;)

    But, for text (that includes HTML) ... i will continue to use HTML::Template or Template, simply because each HTML document gets to live where it should: inside an HTML document.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]
      The reason i spoke up against your original HERE DOC code is that you cannot convince me that storing HTML inside some Perl code is better than storing HTML inside it's own .html text file.

      But, tell me ... how do you achieve conditional branches and loops with HERE DOCS

      So now it's you trying to convince me, that it actually is better to store HTML *plus* code (conditional branches and loops) in "its own" .html text file.

      Brother jeffa: Either you must be blind or just kidding (a lot). If I'd want that, I'd be using Zope (which we actually do for our WWW).

      Bye
       PetaMem           All Perl:   MT, NLP, NLU

[reply]

        No, i am not kidding at all, but i may very well be blind. Then again, you just admitted to having to use Zope ... no wonder you have such a bad impression of HTML templating. ;)

        However, i finally understand what you are arguing against. Perl grabs HTML which contains more Perl. But you know what? I don't think that is bad at all. In fact, i think it is wonderful! You seem to be more concerned with premature optimization than maintainability and readability. Yes, your way executes faster ... but does it even matter? Remember, the Internet is a Von Neumann Bottleneck. Who cares if your templates generate 5 seconds faster than mine if it takes 15 seconds to send them across the wire. And more imporantly, who cares if your templates generate faster than mine if it takes the HTML developer longer to understand how to even make changes, much less where to find what needs to be changed.

        Besides, are tags like <tmpl_var>, <tmpl_if>, <tmpl_loop>, and <tmpl_include> really "code"? Well yes, but it is a very slimmed down code, now, isn't it? This isn't very much for an HTML designer to have to understand. Now, granted that Template Toolkit is much more complex and does allow for full out Perl code ... but i don't use it with a team. (And besides, Template Toolkit is FUN man! Don't you like to have fun coding?!?)

        Listen. If it's just you or me that's handling the whole darned web site (coding and design) ... then pick whatever floats your boat. But if you are working with a team of HTML developers, i garuantee you that they will be more comfortable with: 

        <table>
<TMPL_LOOP data>
<tr>
   <td><TMPL_VAR foo></td>
   <td><TMPL_VAR bar></td>
   <td><TMPL_VAR baz></td>
   <td><TMPL_VAR foo></td>
</tr>
</TMPL_LOOP>
</table>

        [download]
        than:

        Um ... how the heck do you even do that with Text::Vpp?!? Nowhere in the docs is mention of how to use a FOREACH loop. Instead you have to delve through the undocumented test scripts and nowhere is an example of looping through a list of hashes. Also, nowhere is there a mention of using Text::Vpp to drive dynamic websites. This is really starting to look like the wrong tool for the job ... (and get this, the module hasn't even been updated in the past 2 years!)

        Even the docs for Text::Vpp warn you against adding complexity to your code: 

        
Adding Vpp syntax in your code will make it more
difficult to maintain. Even more so if the code maintainer
will not be yourself. Furthermore, the build procedure may
also be more complex. So please, do consider the trade-
off between speed and complexity.

        Sure, the context is about using Text::Vpp to pre-process your code to gain speed, but again ... nothing about using Text::Vpp to drive dynamic websites. Now i start to really believe that this is not the right tool for the job. Please stop making me waste time on this pointless, pointless, pointless argument.

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]
Re: Re: Re: The scope of templates
by tilly (Archbishop) on Nov 30, 2003 at 19:30 UTC
    Since we are all discussing doing this for a living, the job experience that you described strongly suggests that you are in fact a PHB, immediately rendering suspect any technical judgements that you make. :-P

    That said, I agree with your list of what matters and where the dangers are, but disagree with your ideas on how to get there. My general perspective on what should feed templating decisions can be found at Re (tilly) 6: Code Critique. The biggest single factor in most cases is that your decisions here determine who must necessarily be involved in different kinds of maintainance going forward. To me this fact is massively more important than factors such as how dynamic the content of the site is.

    Both of these are a bit dated, but I still like the overview offered by this white paper on Template::Toolkit and Choosing a Templating System. The second one has an update coming, so you should talk to perrin about any templating-like system (eg Text::Vpp) that you like, telling him how it works, and why you like it.

    The overhead offered by a good templating system is miniscule. For instance it is not a good bet that heredocs are going to be faster at runtime. But it is a good bet that the decision to use heredocs guarantees that pretty much anything involving touching HTML will need to involve a programmer, and anything involving changing the overall layout of the page will likely involve tearing your hair out. (CSS can only do so much of that for you on a complex site. Try rearranging what pages have what content and...)

    It is also far from guaranteed that the decision to use a templating system will result in your winding up with well-defined data components that HTML people can manipulate without having to learn how to program. But you have a chance to get there if that is your up front goal and it really makes sense with how your company is organized.

    So my personal opinion is that while heredocs are sometimes justified (I have certainly sometimes used them, particularly in cases when I will be the only maintainer and what the script does is simple), choosing to go that way limits the tradeoffs that you can decide to make. And normally there is a better tradeoff available which can be reached with a templating system.

    Of course the flip side is that reaching the right tradeoff will also mean having the programmers only using the extra expressiveness that the templating system offers to express the solution that you want..and no more. Unwarranted further use of available expressiveness is an option that I agree can quickly lead to a big ball of mud. But there is no reason why it can't remain just that, an unused option.

[reply]
Re: Re: Re: The scope of templates
by zby (Vicar) on Dec 01, 2003 at 11:02 UTC
    Mine view is that it is not about separation of code and data - but rather about separation of business logic and presentation. This is a valid line of separation. Presentation beside pure visual treats does include some logic and thats why logic is supported by the templating solutions.
[reply]
      Actually I agree with *this*. If there is a justification to export code (not just static content plus some "interpolation") to a templating system, it might be exact for this reason.

      But I have a hard time to see where it would improve maintainability, because then in order to change the presentation layer (template) you have to send your programmers too. (One of the arguments was, that templates don't need programmers. More precisely - the work on (changing) templates.)

      And as for the programmers: I have an *extremely* hard time to see where this code splattering would improve readability.

      Bye
       PetaMem           All Perl:   MT, NLP, NLU

[reply]
        It is all about choosing the right tool for the job. The presentation layer is so much different from the business logic layer that it is usefull to have a different language to code it. And with a big and complicated project the cost of introducing a new language will be justified by the big chunk of such coding.
[reply]

In Section Seekers of Perl Wisdom