Properly abstracting and separating the different layers should help make this a lot easier to do. I've had very good results using HTML::Template in conjunction with mod_perl. Here's how I'd suggest breaking things down.

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

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.