Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re: Re: OUTPUT: inline or template_based?

by CodeHound (Beadle)
on May 28, 2002 at 13:25 UTC ( #169757=note: print w/replies, xml ) Need Help??

in reply to Re: OUTPUT: inline or template_based?
in thread OUTPUT: inline or template_based?

Phew was it there stuff to read... however I have noted one post in particular which tells that the community is simply divided by which technique is better... and I sincerely could still not determine what fits best the common practice.

Point is: I don't have experience on the subject, so I was interested in Monk's opinions to make up my mind before doing serious coding.

As of now, I prefer inline code... most simply because I dont have still understood (nor found) practical examples of WHY templating IS better.

To maybe enrich the concept some more... suppose that the templates need not be modified once the APP is deployed... wouldn't it be an unworthy effort to code for such use and open a vulnerability in the application?

Many thanks everybody
  • Comment on Re: Re: OUTPUT: inline or template_based?

Replies are listed 'Best First'.
Re: Re: Re: OUTPUT: inline or template_based?
by tomhukins (Curate) on May 28, 2002 at 13:52 UTC

    The main advantage of separating code according to the technology used is that different people can work on different parts without getting in each others' way.

    HTML developers can change the templates and Perl coders can change the programming without having to deal with unfamiliar technology.

    Inline code is fine if you are certain that all developers working on the project will be able to and have time to understand both the Perl and HTML. If there is any possibility that changes will be required in the future and you don't know who will make those changes, use a templating system. In practice, this happens on any successful project.

    Separating the programming logic (model), the HTML (view) and the page generation code (controller) allows developers to specialise in their own areas, makes code more robust and gives you the flexibility to add new or multiple front-ends in the future.

    Given how easy it is to incorporate something like Template::Toolkit or HTML::Template into your code, I can't see any reason not to. Typically, to create a template object, pass parameters, and output the HTML (or XML, or whatever you wish to output) takes less than 20 lines of code.

You want to use templates...
by jarich (Curate) on May 29, 2002 at 06:18 UTC
    As of now, I prefer inline code... most simply because I dont have still understood (nor found) practical examples of WHY templating IS better.

    I did it this way too. My client gave me a hunk of ugly HTML code. It produced some very pretty pages. My client is a HTML developer. She's very very happy to edit HTML.

    I thought I knew better. I rewrote the HTML into CGI functions and wrote all the functionality she was paying me for around that. When I looked at the pages they looked similar enough to me.

    I thought I was being clever. I knew nothing about HTML::Template at the time. I knew next to nothing about templating. I was only doing my 3rd year of a Software Engineering degree. I knew about data separation, but I didn't think of HTML as data.

    Then came the change requests. My client wanted the <TR> tag moved to here, this change, that change. Please remove the whitespace at this point as it breaks some browsers... Argh! She wouldn't touch my Perl code (which of course isn't all bad) so every single time she wanted the interface tweaked she called me. And of course I couldn't charge her because it was my fault!

    Heaven forbid should she ever want the page changed in a major way. I have now ripped out the top and bottom bits and let her template them, but what about all the little bits?

    Oh how I wish I'd used templates! Even simple ones that are just text files with REPLACE_ME tags in them would have been better.

    When people tell you that if you don't use templates you'll regret it, they're right. If you code your HTML in to your code using HERE docs then it's a _little_ easier for the HTML person to fix on their own, but then you can run into the double update problem. I've had that too (although with PHP):

    My client rings me and tells me that whenever she tries to load the page (on some pages) it seems to go into an infinite loop. I check the code, and she's right. For some reason $x-- doesn't work if $x is a float in PHP (so $x = 3.5; while($x > 0) { $x--; } won't ever stop).

    So I change it to $x -= 1; and tell her it's fine. She thanks me and rings me 5 minutes later to tell me that it's broken again. What? I check and it is broken again. I fix it again and it breaks again. What's happening? Ah! She's changing the HTML embedded in my code and uploading her version over my fixed version again and again. At this point I grumble about CVS and explain to her than when she's done with her fixing, it would be nice if she'd make my change on line y.

    Templating is really the only way to go. Even though it's a pain to learn and even though you think that the design is set and you won't ever, ever, ever need to redesign the webpage you're producing.

    Good luck


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://169757]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (1)
As of 2022-11-26 15:55 GMT
Find Nodes?
    Voting Booth?