First off, to really start using CGI::Application, you will need to understand at least some rudiments of perl OOP. The first time I looked at it, I didn't understand perl OOP at all, and I quickly dismissed it. However, once I'd grasped the fundamentals of perl OOP, I went back and looked at it and liked it much more. Contrary to what merlyn says, I don't find the guts of it to be monolithic; in fact, I was shocked to discover how lean it actually is, considering what all it lets you do.

To address some of your specific issues:

• One script for one run mode is asking for trouble when the run modes are all linked by a common theme. What CGI::App does is have you group run modes -- so that all operations relevant to a process are in one place. However, you don't necessarily need all these run modes in the same file; that's why namespaces are so much fun -- simply load up the appropriate file with the run mode you're requesting when you need it, or load them all up when the initial module is loaded.
  
  The beauty of doing it like this is that if you group the application code, you know where all of it is. Additionally, using the dispatch table provided by CGI::Application, and which you setup in your class, it becomes very easy to determine what method is invoked at each point in the application -- making debugging very easy. Look up the run mode, then find the method... you're there.
• If you want to build reusable applications, CGI::App is your friend. Build an application module once, and use it many times. You can customize your application using metadata passed via the instance script (such as template location, DBI parameters, etc).
• You don't have to use CGI.pm; you can override the query() method to have it pull in CGI::Simple or some other module that gives you access to CGI parameters. For that matter, you aren't tied to HTML::Template, either; you can use any templating system you want (or none at all), simply by overriding the appropriate method(s).
  
  This kind of flexibility is one of the key strengths of CGI::Application, in my opinion.
• If you have multiple applications, but you want them to share some common parameters -- templates, session handling, etc. -- again, CGI::Application is your friend. Build a superclass for your site that performs these actions or sets up your environment, and have all the various application modules inherit from it.

Again, you need to have a basic understanding of how OOP works in perl, but once you do, CGI::Application becomes a breeze to utilize, and an incredibly flexible tool. It's not the be-all, end-all of web programming, but it provides a nice, lightweight framework for developing web applications.

---

---

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.