Re: Code and html separation - always or mostly doable?

I come down firmly in favor of keeping code out of templates.

The project I'm on now assembles HTML hierarchically, using HTML::Template-based fragements to assemble larger pages. This lets us build reusable components while still keeping our HTML separated from our code. Consider something like:

    <h1>Here somes a table</h1>
    <TMPL_VAR NAME=table ESCAPE=0>
    <hr>
[download]

On first glance, you might assume that table is a chunk of HTML table tags generated from code, but nothing says that it can't be the result of expanding a different template and stored the resulting HTML in a hash that gets used when constructing arguments for the outer template.

Comment on Re: Code and html separation - always or mostly doable? Select or Download Code

Replies are listed 'Best First'.
Re^2: Code and html separation - always or mostly doable? by amw1 (Friar) on Jun 17, 2004 at 17:08 UTC
I used to come down firmly on keeping all logic outside of the templates. However I ran into a number of cases where it was either put code in the template or put display only logic inside of the program. An example of this was date formatting. All of our routines that get data structures from the database/files/aether etc. return times as seconds since epoch. Much of our backend code makes use of this number without ever converting it. In fact, the only time we ever need to cook that number is when we display it. After cooking the date in the cgi and passing it to the template I started to think that it made no sense to do this work inside the CGI as it had nothing to do with the actual work of the CGI. i.e. the cgi was no longer agnostic wrt how the data was displayed. After spending some time thinking about this I started to draw the following lines: Anything that does work other than calling a template or processing form submissions lives in a module. Anything that does work that is display only (formatting things (like dates above), colors, layout etc) only lives in the template. Yes, this often leads to having some programming inside the template, I just felt since it was only for display it made more sense here. Everything else lives in the CGI. The only time I end up breaking this is for things that make a ton more sense to do in a langauge other than the template. (i.e. heavy data manipulation etc) but I try like the devil to code my way around that. It may have been my lack of experience with H::T but I found myself having to re-form many of the data structures we were using into AoH's for use by H::T. With TT I was able to use whatever datastructure I wanted to pass to the system. Again, this lead to a bit more logic in the template, but it was for display only. Using the cgi to reformat data for the template seemed like a huge waste of effort. Granted, we could have re-formed the datastructures from the backend but there were more places where it made sense for us to use straight hashes than AoH's. Since H::T (to my knowledge) won't process a hash I had to spend more time writing code in the CGI that ultimately did nothing but format data for display. my .02	[reply]

Replies are listed 'Best First'.

Re^2: Code and html separation - always or mostly doable?
by amw1 (Friar) on Jun 17, 2004 at 17:08 UTC

An example of this was date formatting. All of our routines that get data structures from the database/files/aether etc. return times as seconds since epoch. Much of our backend code makes use of this number without ever converting it. In fact, the only time we ever need to cook that number is when we display it. After cooking the date in the cgi and passing it to the template I started to think that it made no sense to do this work inside the CGI as it had nothing to do with the actual work of the CGI. i.e. the cgi was no longer agnostic wrt how the data was displayed.

After spending some time thinking about this I started to draw the following lines:

Anything that does work other than calling a template or processing form submissions lives in a module.
Anything that does work that is display only (formatting things (like dates above), colors, layout etc) only lives in the template. Yes, this often leads to having some programming inside the template, I just felt since it was only for display it made more sense here.
Everything else lives in the CGI.
The only time I end up breaking this is for things that make a ton more sense to do in a langauge other than the template. (i.e. heavy data manipulation etc) but I try like the devil to code my way around that.
It may have been my lack of experience with H::T but I found myself having to re-form many of the data structures we were using into AoH's for use by H::T. With TT I was able to use whatever datastructure I wanted to pass to the system. Again, this lead to a bit more logic in the template, but it was for display only. Using the cgi to reformat data for the template seemed like a huge waste of effort. Granted, we could have re-formed the datastructures from the backend but there were more places where it made sense for us to use straight hashes than AoH's. Since H::T (to my knowledge) won't process a hash I had to spend more time writing code in the CGI that ultimately did nothing but format data for display.
my .02

[reply]