My favorite is either Template Toolkit or HTML::Template. Both keep the code and HTML seperate, which I think makes everything much easier to deal with as you keep the presentation of your content seperate from the logic of the program.

HTML::Template is useful if all you need to do is replace values in a template, perhaps with some simple conditional processing. It goes to the extreme of keeping code and HTML seperate.

For anything very complicated, I go with Template Toolkit as it allows the construction of fairly complicated templating systems and has plugins for various things. It does mix code and HTML a little and even has something of its own language. But I've found that once you start dealing with templates that can end up looking very different based on user input, that extra flexibility gained by having some code in the template ends up making things much easier to understand (though I think you should still keep most of the logic in the Perl program that is calling the template and avoid using callbacks). Template Toolkit does have a little bit steeper learning curve, but once you understand the basic syntax, it's pretty easy.

If you haven't seen it before, you may want to read my article about templating systems. There are also lots of discussions on this site about them.

Excellent article, exactly what I was looking for. Thanks :)

As for specifying XHTML, no special reason other than that's all I plan to use, so other output formats are largely irrelevant. Thanks again.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Hi, thanks for the reply. Just to clarify I'm looking for XHTML templating systems, conversion from XML is not required. Is AxKit still the best choice in your opinion?

I just use HTML::Template. No code in the XHTML, no XHTML in the code, and dead easy to use.

I'm not really sure what you are after, so I can't give much more of an answer than that.

I'm using the HTML::Template in my project. The examples given in the tutorials are pretty simple - one or two tables. However, if you take a normal website, it contains 2-3 menus, a few link boxes, page content, header, footer and other things. So, there is a need to break the homepage into small templates. Here we go: I have ~ 30-50 templates in my project. I'd liked to hear from othe perl monks how they deal with such situation, because I believe most of the websites are pretty complicated.

I use HTML::Template together with DBIx::Recordset at my work. As I have already noted I have ~ 30-50 templates for different entry forms and website components such like button groups. I use template includes and loops, trying to make them as abstract as possible.

I'd liked to hear if anyone is writing such modules like Menu.pm that loads its entries from the database and knows how to display its items using the templates. There are many components which I needed for my website and had to write myself. I believe there must be frameworks like that around, but I don't know any.

You feel so strongly about this "need to break the homepage into small templates" that you bolded it... I don't understand why you need to do that. Perhaps you are going about it backwards?

If I have to do a complicated page, I do a mock up (I have to plug TopStyle Pro here... it's a great editor for XHTML if you're a windows user....) that looks exactly like I want the page to look when it is dynamically generated.

Then.... well, my work is just about done. I replace the mock up data with TMPL_VAR and TMPL_LOOPs and then write some perl that does all the right stuff to populate those variables.

I don't have to split my XHTML pages into tiny bits, so I don't understand why you would have to be splitting your templates into tiny bits!?


Apsyrtes

I quite like mason.

Thanks for all the suggestions everyone :).

In the end I decided to write my own - don't worry, it's not like it's a parser ;), but I'm sure I'll find uses for other options later on.

Why did you decide to write your own? I'm sure there are plenty of people willing and able to add any missing features to the existing solutions and plenty of people willing and able to point you to or even write better documentation for the existing solutions.

And this is exactly why I dropped my own OO-RDBMS wrapper and moved over to Alzabo. The essence is that instead of starting my own project because the existing packages aren't "good enough", I can take something that is mostly what I want and add onto it. Just today I'm adding a YAML serialization to it.

Its easier to extend and alter something that already exists than to create something new.