Top Level Handler

This is specific to either mod_perl or the CGI environment. Have it do all the work of talking to Apache / the browser. Parameter parsing, session management, DBI connections, etc, etc. Basically all the things that could be different between mod_perl and CGI.

Page or function level objects

Takes a list of parameters, session info, DBI handle, etc. and returns a data structure of some sort based on the input. One of these handles a particular page or function in your app. These do not contain any mod_perl, CGI or (insert template mechanism here ) specific things.

HTML suitable for which ever template mechanism you use

The benefits to keeping your HTML out of your code are very, very numerous.

So the chain of events goes kinda like this. The CGI or mod_perl handler, gets called for every page in your app. It does all the 'common stuff' that every CGI or mod_perl handler does. It then calls the appropriate page handling module passing along all the parameters. The page handling module does whatever processing you need for that page (database calls, generation of error message), and passes back a data structure of the results. The top level handler takes that structure, feeds it through the appropriate template and send the output to the client.

Here's some of the benefits.

• One piece of code to modify or replace if you change from a CGI to a mod_perl environment
• Page handling modules are not dependent on the environment. In fact they are not dependent on being in a web environment at all. That sets you up nicely to do testing on them with something like Test::Unit
• Logic is not tied to presentation, and it is only tied to the presentation method in one place. So if later down the line you decide that (template method A) bites and you want to use (template method B) you only have to change code in one place.
• You'd be hiding most of the hairy parts of dealing with either CGI or mod_perl from a team of programmers helping you write this app. All they have to know is the page object API that you create and that should be much simpler than teaching a team of programmers the intricacies of CGI or mod_perl.

Good luck, and I hope this helps.

/\/\averick

Maverick is spot on. As a primarily a graphic designer rather than a coder, seperating your design from your code makes a world of difference down the track when a redesign is due.

Working with a neatly OO web application written in mod_perl/HTML::Template etc. is always a pleasure.

iordy.com

Here is a post that should help you take it for a test drive http //forum.swarthmore.edu/epigone/mason/ gimpswumfrex/Pine.SOL.3.96.990917144751.17640B-100000@simpukka

Essentially this method runs all mason requests through a cgi script that calls the mason files for you. It allows you to maintain a single code base that will run under both mod_perl and CGI. Although you'll have to forgo certain fancy mod_perl only features, (like overriding the authentication phase with your own custom perl module, or dynamically configuring apache depending on which machine it is running using perl tags) this shouldn't be an issue if you start in a CGI environment. (a site built on mod_perl first might have difficulty switching back to CGI, if it used these "fancy" features)

You'll also probably have to customize httpd.conf a bit for this to work. If that isn't an option, I'm not sure if this solution will work for you.

-Blake

Thanks for your answer!

I think HTML::Mason looks great but, like you said, the use outside of mod_perl seems kludgy.
Apache::ASP uses the same trick. You call a Perl script called "asp" which emulates the mod_perl environment.
The latest EmbedPerl won't work with CGI, but they are working on it.
So far Apache::ASP looks most promising. I had a few errors running through the examples in the distribution, but most of them worked.

Beyond that, if you want to abstract the program logic, I like stuffing it into a database, or an XML document.
--
Snazzy tagline here

(To you and to the other HTML::Template voters)

Yes, among the different templating modules HTML::Template looks most promising. I have used CGI::FastTemplate before.
What I would also like to have is session handling, object orientation, and all the things CGI.pm gives me, without CGI.pm.
But if HTML::Mason, Apache::ASP and HTML::Embed are dead ends, HTML::Template would have to do.

I'm using HTML::Template right now, and I recently found out for real just how nice it is to separate the design from the code when a designer gave the application I'm working on a facelift. I didn't have to change a single line of my code. She didn't have to learn anything about perl. I didn't have to stop working on my stuff while she made changes. In fact, I didn't even know she was doing it until she plopped the new templates in place and the pages appeared with the new design!