--
RatArsed

I have used embperl and the extensions for building sites, EmbPerl::Object. I cannot comment on Mason, but it seems to be pretty good as well.

Advantages of EmbPerl::Object:

• It has good seperation of code and HTML - so it doesn't freak HTML types out;
• Simple and easy to learn - I taught a person with little exposure to any form of CGI programming (and perl) how to manage the large site I had developed using embperl::object, and she picked up the concepts, and was able to take over my role within two days.
• An easy to implement (and easy to understand) heirarchical "object inheritance" mechanism - so you can easily have a different page element, such as a side navigation bar, for a subset of your site;
• An active and well supported mailing list.

One other big advantage - you can control what pages are build by embperl. You could say that anything with a ".html" extension is to be managed by embperl, and if you have those pages that you wish to be untouched by embperl, simply call them "foobar.htm".

Rather than serving the web pages as usual, but allowing big chunks of programming inside them (or, even worse, makng you put chunks of HTML inside your perl), HTML::Template has you create what looks like a plain HMTL file, but with a few special tags in it. Mostly just variable values, with a few rudimentary control structures thrown in. You hand HTML::Template the template, and the values with which to fill in the blanks, and your finished web page comes out the other end.

(up on my soapbox)
This is the way things should be. Separate design and content -- in this case the code is the content. These boundaries let the approrpiate experts do their own jobs without having to try and learn too much of someone else's, and without tripping over each other editing the same files. It makes life much easier down the road when either the code or the presentation has to be converted to something new. It even works for you in the area of code reuse. Once you've got this nice web-based application, you can easily reuse most of that code -- virtually untouched, if you've been careful -- to function with a screen-based interface or a batch processing system or whatever someone thinks up next, just by modifying the input and output bits on the edges.

A further comment. What is it that you are actually looking for to tools to do? Are you wanting an easier (or at least, easier) way to maintain a large (greater than 50 page) site, to ensure all pages have the same style, use the same navigation widgets, and when some common feature is to be changed across all pages, to make sure that is done quickly and completely?

If that is your need (even without the need for CGI programming, pages built dynamically from data base content, and the like), you will need some form of site builder that uses standard and common "objects". EmbPerl::Object is ideal for this, as is (I believe, having never used it), HTML::Mason. HTML::Template may be as well, although I though it didn't directly support the concept of "plugging in" standard elements.

Let me give an example. You want to have at the bottom of every page, a copyright line, with a hyperlink to the full legalese copyright statement. You could put in something like this:

<a href="copyright.html" style="copyright">&copyr; Semper Kludgiemus I
+nc 1999-2001</a>;
[download]

This is where EmbPerl::Object and HTML::Mason come into their own. You have one overall "master page", which will include a copyright line similar to it in the appropriate place. Or, better still, a call to insert the copyright line "object". Since all your pages are build using this master template, there is only one place where the HTML source of your copyright line is specified. Change that once, and the change is reflected on all pages built.

With HTML::Template, you either use included files for the common elements with TMPL_INCLUDE, or you make the date range a TMPL_VAR.

I agree, though, that taking a good hard look at what you're trying to accomplish and then picking a tool makes a lot more sense than doing it the other way around.

--
tune

On top of that, I have at times pursued the commercial support options for Embperl and other HTTP-related technologies and I don't know of such features for Mason.

Finally, Embperl is supposed to be moving away from HTML-dependency and will support XML generation as well. And Embperl works in 3 modes: offline, CGI, mod_perl. I believe Mason operates in the latter two, but certainly not the first.

That being said, XML seems to be all the rage and the two web application environments for Perl which are XML-oriented from the bottom up are AxKit and Apache::PageKit and I am doing a webapp using AxKit on the Perlmonk's user site right now after finding CGI::MxScreen to be a bit limited in its paradigm.