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

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)

Replies are listed 'Best First'.
Re: 3Re: The scope of templates
by PetaMem (Priest) on Nov 30, 2003 at 12:53 UTC
    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]
        A tip.

        If your website has decent volume and you are using mod_perl with lots of dynamic content (hopefully with templating), then you probably want to be using a reverse proxy setup. See this guide (particularly Adding a Proxy Server in http Accelerator Mode) for an explanation of what it is and what the benefits are. From your point of view the big benefit is that a mod_perl server ties up a lot of memory, so that configuration allows you to have fewer big mod_perl processes all actively producing content, and let the proxies take care of returning data over the slow wire to the browser.

        After you do that then the answer to your rhetorical question about why it matters how fast the mod_perl executes is that improving speed there will reduce how many heavy mod_perl children you need for a given load, which will save on memory and CPU requirements (which translates into the number of webservers that you need).

        Another detail. What I (and many other people) dislike about Zope has nothing to do with templating. In fact I dislike the same thing about the way that this website is designed and the way that many Smalltalk and/or Lisp projects are run. And that failing is that Zope wants to store an opaque binary image (in its case in an object database) that includes HTML and code. That immediately takes the wonderful world of filesystem-based tools (everything from grep to revision control tools) and throws them out the window. Work its way and you have to reimplement all of them, and learn the new toolset just for Zope. And if it gets them wrong, then enjoy trying to manage your releases (eg roll code forward and back).

        This design decision is completely orthogonal to whether or not to use templating, and it seems that you missed it.

        I won't comment on your other points since I mostly agree with you.

[reply]

In Section Seekers of Perl Wisdom