HTML::Template - what's the rule of thumb?

[kiat]

Greetings to all monks,

Correct me if I'm wrong...

One of the uses of HTML:: Template is to allow the separation of (e.g. html) content and (perl) code. The code generates the data (say from a database) and delegates the output to a template. The objective here is to minimise the mixing of html code with program code in a script.

My questions are: Do we try to maximise the use of a particular template by making it as generic as possible? Or is it okay to have different templates for different outputs? What is the rule of thumb on the use of a templating system?

I look forward to hearing your views.

Thanks :)

Update

Great thanks to all who have generously shared their experiences on using a templating system, in this instance HTML::Template.

I'm now in a better position to decide when and when not to try and maximise the use of a particular template. Before, it was a judgement largely based on gut feelings, and it just didn't feel right.

[dragonchild]

I generally have one template family for each CGI script. (I use HTML::Template, PDF::Template, Excel::Template, and Graph::Template in conjunction with one another. Thus, there are four templates, each describing a different output format for the same layout.) Sometimes, two scripts will share a template, if the same layout is used, but with different calculations. Sometimes, a script might have more than one layout, depending on what it might do (though that's very rare and should, IMHO, be avoided). But, 1-1 is my most common thing.

Now, <TMPL_IF>'s are not all bad, but if you start having a bunch of them, and they're unrelated, you should probably break it out into a bunch of templates, using <TMLP_INCLUDE>'s and make things easier on yourself. Remember - you should be separating display from logic. If you need to have a bunch of display-logic in your logic, you haven't really made things easier on yourself, have you?

[kiat]

Thanks, dragonchild

But, 1-1 is my most common thing ... Remember - you should be separating display from logic. If you need to have a bunch of display-logic in your logic, you haven't really made things easier on yourself, have you?

That's reassurring to hear. I'm kinda facing a dilemma deciding on how best to use a template - a decision between having a template serving a couple of different outputs (hence, requiring possibly some display logic in the template) and being more generous in the creation of templates for different outputs.

It's a delicate trade-off, no doubt. While it makes good sense to have similar outputs share the same template, trying to push things to the limit will only make easy things difficult (which is so unperlish :))

I'll remember this when I remember one of perl's virtues: Easy things should stay easy.

[bradcathey]

I've been following, and enjoying, kiat's recent posts because as a web designer I feel we are on parallel journeys in learning how to use Perl to support our development. Thanks kiat for your unabashed posts.

Web development in our shop is done as a team effort. We have the account folks to cast the vision; graphic designers to develop the look, feel, navigation; and then a programmer or two to make it work--connecting the web-based content editors with MySQL and Perl, similar to kiat's scenario.

Before we discovered HTML::Template (H::T)*, all our output was heredocs. This drove the the designers crazy--to make even a small change they felt they had to rely on the programmers (designers can get nervous around Perl). In fact, it frustrated everyone because it took two bodies to make the revision--inefficient to say the least.

H::T changed that, of course, because the subtle design changes could be made without bothering the rest of the team. But not completely, because we were still including too much HTML in the Perl scripts. However, as we have moved more HTML back to the templates docs by using, as barrd points out, the H::T conditionals, we are giving more control back to the designers--all the HTML is accessible to their layout programs (Dreamweaver or GoLive).

All that to say: the rule of thumb in our shop is to distill our code down to the point where we are using every possible convention of H::T to keep as much HTML in the .tmpl doc as possible. So, anytime something needs to be displayed in the browser window, whether a full-fledged content page or a simple error message, an .tmpl doc is doing the work. The look and brand of the site is maintained. Bottomline: keep code and HTML as separate as possible.

*I realize there are other templating systems, we just happened to get hooked on H::T

[adamk]

Here Here!

I believe too many programmers don't think enough about division of labour issues like this.

When doing any Application + Templates type work, you should be looking to seperate form and function as much as possible. And this often means making your templating system as stupid, simple and web designer friendly as possible.

Ideally, you want to be able to write your application code anyway you like and have ex-receptionist-web-designer-who-doesn't-know-HTML-but-can-work Dreamweaver, or clueless-Marketing-Director-that-likes-to-tweak-the-copy-on-pages, to be able to make changes here and there and not be able to break it. Having other people doing non Perl related things is GOOD!

For the next step, they should also be able to use things like Dreamweaver Templates and Library items across both the static website AND your dynamic templates and have it "just work"

Get something like this working well, and your designers will love you, and be much more efficient too. Hey, we have to compete with India somehow, and the more efficient your people are, the less likely the role is to be shipped offshore. :)

It's also the primary reason that I've been saying for years that ASP/JSP/PHP or any other server page type languages don't scale up enough, because it's way to easy for the above mentioned people to break it.

[liz]

I would say "Whatever works best in your situation". And "Be consistent". And "Document your code well". And possibly even "Document your HTML well".

For me personally, I would use different templates for different outputs. But if the logic for different outputs is the same, I would try to have that at one location, rather than having to maintain two identical pieces of code or HTML at different locations. Your templating system may or may not allow macro's or include's.

But without more to go on, there's not a lot more to day, I don't think.

Liz

[barrd]

Hi kiat,
Your question is a bit open ended and really depends on the complexity of the data you are trying to display. I usually try and make my .tmpl's as generic as possible, this though is not to everyones taste and depends heavily on what is required to be displayed. If the data is not too wildly different I rely on <TMPL_IF>'s and <TMPL_INCLUDE>'s to manage what gets displayed and keep any text in the main template as generic as possible with all the dynamic data being shown in the included templates.

[swngnmonk]

Without looking at what you're doing, it's hard to offer suggestions to your specific site.

We use HTML::Template (and CGI::Application - check it out!) for all our CGI work, and at this point, we're pretty consistent in how we use it. The biggest help is that since you can put HTML::Template logic in your include files, we generally create top & bottom containers (headers, navigation, footers) with their own logic (if needed), and include them on all the other templates. The additional benefit is that you can then create a sub to populate the containers, and call it as needed, cleaning up your code further.

I've found that anything as small as a table, if used on multiple pages, makes a good candidate for an include. It means that both in your HTML and your perl, you'll have only one place to maintain it. Generally a good thing.

So don't try and make a single template as generic as possible - it makes things too complex and difficult to maintain. Take the common elements in all your pages, split them out into includes. The end result will be a lot cleaner.

[punkish]

One of the uses of Template::HTML is to allow the separation of (e.g. html) content and (perl) code.

You really mean HTML::Template ;-) Maybe you should update your topic for future searchability sake.

That said, yes, not only "one of the uses," it could be argued that the only use, rather, objective of H::T is to separate display from code. In most sites, however, it is not possible to achieve 100% separation. For example, if you are displaying rows from a table (a common implementation in most dynamic sites) you want to colorize the rows with alternating light/dark colors to improve legibility. Obviously, you will need a teensy bit of logic in the template to be able to do it.

However, separation of display is not only for aesthetic purposes but also for granting the ability to edit/design/improve the aesthetics to those who are right-brain endowed but might be coding-challenged. Right person for the right job.

Also, what about the right tool for the right job? Most coders would agree that a simple to muscular text editor is the best tool for coding. But doing CSS, layout and site design is probably better accomplished with something like GoLive or Dreamweaver or other such. For example, all these visual tools provide the ability to diagram the site with its various linkages and whatnot.

Based on the above understanding, I maximize the power of H::T by designing different templates for different outputs. I try to design a site where if I were to open up only the .tmpl files in GoLive, it would still appear as a site. Or, were I to navigate through a structure of .tmpl files using a browser, I would still be able to "walk" through the shell site.

Needless to say, there will be common elements that may want to populate the entire site with -- well, the TMPL_INCLUDE tag and the filter option in H::T rise up happily to the occasion. With judicious use of these capabilities you can maximize the power of H::T, design a site which can, if required, be handed to someone who is really skilled at making it good-looking while you can concentrate on working on the grey matter.

I believe the above would be helpful even if you yourself were the right and left brains of your coding team of one.

Hope this meta-discussion helps you in your coding. In the end, there is no rule of thumb. If it works for you, it works.

[stvn]

Kiat,

We use HTML::Template alot at my work, and i try to follow this general process:

1. Prior to touching any code at all, I do my best to work with the information-architect and/or graphic-designer/interface-designer (or equivalent person on your team) to try and group "like" pages together. This not only helps me in my coding (and code re-use) but it tends to produce a much smoother end-user experience as well. This is akin to planning out your modules and their interfaces/APIs in software engineering. ( a quick note here: i find sometimes that designers etc. can be resistent to this, its an exercise in diplomacy, but any desinger worth his salt will see if your idea is good, and of course that means you must be just as flexible)
   
   
2. After I feel I have "normalized" as much of the site as i can (sometimes as a programmer you just have to follow the whims of the designers and account folk no matter how silly it may seem to you). Then i begin to plan out my templates. At this point, like pages can be one template (with any nessecary TMPL_IF or TMPL_INCLUDE statements), and unlike pages in seperate templates. Of course this seems straightforward, but without the first step its not so easy.
   
   
3. After I have the templates built, the easiest thing to do is look for repeating sections, and then chunk them out and TMPL_INCLUDE them.
   
   
4. From there, we connect them to the Perl logic and tweak as nessecary.

We use mod_perl, so our templates are cached in the server's process memory. But even with pre-parsed & cached templates, I make an effort to never let my templates get to complex. Complex templates not only have a higher initial parse overhead (longer startup time for mod_perl server/process and slow pages for vanilla CGI), but they tend to be more complex (read: slow) to execute as well. And most importantly, a highly complex template will increase the coupling between your back-end Perl logic and your front end HTML::Template logic which defeats the whole idea of seperation and you are back where you started.

Oh yeah, and i find that the ability of a non-programmer to handle HTML::Templates decreases in relation to the templates complexity. If you are not only trying to seperate display from logic, but trying to seperate tasks across individuals, your better off keeping it simple.

In the end, there is no direct relationship between our perl and our tmpl files, but this has more to do with our particular use of mod_perl (we use handlers not Apache::Registry, and have a whole OO dispatch table architecture set up going on)

Anyway, hope this helps.

-stvn

[freddo411]

[CountZero]

I'm not fond of templating systems: Either they are too simple (and hence not flexible enough) or they are too sophisticated (and then it is like trying to learn a new language).

I stick with my perl-script outputting XML and relying on XSLT to transform it to HTML (or whatever is en vogue for the moment).

The programmers have access to the perl-script, the graphic and layout people only have to deal with the XSLT (and CSS) and DTD and/or Schema ties it all together.

Sadly, I'm both author of the DTD, the programmer and the graphic/layout designer, so I could as easily use lots of print statements in my perl-scripts. Still it gives a warm feeling doing things in a politically-correct way.

[Willard B. Trophy]

It sounds like you're in a very specific situation, CountZero, and the fine old maxim "Whatever Works For You" applies. But I've never met a designer who could handle XSLT. Precious few programmers grok it, either.

I was initially sceptical of templating systems, but HTML::Template lets me build working templates, which I then pass on to more webly types for prettifying. Template usage needn't be incompatible with web standards, either.

HTML::Template is a fine, general-purpose text templating system. With a suitable text file and MIME::Lite, it also makes a good e-mail templating system.

[CountZero]

I entirely agree with what you are saying: whatever works for one, need not work for someone else.

Templating systems don't work for me, but that should not let others be stopped from using them.

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.

[Anonymous Monk]

It's basically a matter of how you need to weight different aspects of your project. If you're project is pretty simple, and your outputs similar, then it probably doesn't matter. If your outputs are very different then you will run into a complexity problem very quickly. In my experience making a generic master template tends to lead to the HTML dicatating how you write your Perl code, and the more generic, the most this tends to hold true - Now HTML becomes the master of the Perl script. Probably the best trade off (as was mentioned before) is to use <TMPL_IF> and <TMPL_INCLUDE>. You add another layer of abstraction in a way, but it will probably be the most maintanable and offers the most ballence.