The HTML::Template module served us well for quite a while. It was our first really strong attempt to segregate the program code from the display code and do as much as is plausible with CSS. It worked pretty well.
After we’d been using HTML::Template for a while we discovered there were a number of things we needed to do that didn’t really fit the way HTML::Template wanted to work. That’s par for the course: you switch to some new tool, there’s some settling it, but everything is swell… until it isn’t, and you work around the issue. Totally expected.
For example, the site navigation elements on a page might be somewhat dynamic, based on context: color, spot graphics, link order, “bread crumbs,” other perceived affordances, etc. We looked at a number of ways to create these on-the-fly items. We eventually settled on using a function to do the necessary analysis and work (perhaps using template for formatting) and returning the resulting HTML. The HTML was stored and later passed as a bulk substitution in the final HTML::Template for composition.
As time passed, we found we were using this technique for many more things. The main program called functions that had their own template (or templates, or created “templates” on the fly, which sometimes used other templates) which would be parsed and populated. The resulting HTML for each of these items was stored and passed to the final HTML::Template for composition.
Other approaches to this issue had the program code constructing “deep” data structures so they could be fed to HTML::Template control structures for page composition. “OK, so this is an array of hashes of arrays of arrays of hashes… of hashes… of arrays… that do what again?”
Random musing: What I want is some tool that takes Data::Dumper output and lets me poke around in it, like a tree view or something. And a pony.
This finally reached the stage where we were contemplating an HTML::Template parsing engine so we could recursively include the output of referenced templates… but this didn’t actually go into production.
Switch To Catalyst
We could have continued to use HTML::Template when we moved “Secret Project #560” to Catalyst. However, so many other things needed to change (or we chose to change them) that we decided to go whole hog and switch to Template Toolkit. All the groovy Catalyst apps were using it, so we thought we’d try it. Just the once.
So far, so good. The transition wasn’t too painful, converting sites proceeds apace, and we’ve yet to find irredeemable complications arising from Template Toolkit. Time will tell, of course.
More as it happens.