I don't really have an answer, just more questions. I think the idea of CGI::Application is appealing, but falls apart quickly in the real world, especially if one takes the "one module for the whole application" as a feature:

• if everything is in one module, coordinating across several developers is more challenging.
• when I do db maint on a table, I often have eight (or more) modes per table:
  1. search
  2. results (list)
  3. detail
  4. update (sql)
  5. add new
  6. insert (sql)
  7. delete confirm
  8. delete (sql)
  A modest application can easily have 20+ tables, so up to 160 run modes just for table maintenance. Now in practice, I've got a module to do table maintenance (that btw, works on the principal of run modes) that is fairly simple to invoke until you go beyond default behaviors.
• The (file count) "simplicity" of one Perl module seems a bit illusory if you have an HTML template file for each run mode (3-8 for each table maintenance).
• What I do (taking the table maint case further) is to have one script for each table (or group of related tables). This script does, indeed, use the concept of run modes. I wind up with more Perl scripts, but it's easier for several coders to work without stepping on each other.
• When I have code that needs to be reused, it can be developed in the first script that needs it. When working it can be migrated to an "application module" where other scripts can reuse it. But in my case the application module only has code used more than once (or likely to be).

As with a lot of abstraction techniques, getting the granularity right is the key. A web application can be divided up a number of ways. I look at these levels:

• An individual page
• A group of related pages that never go anywhere without each other.
• The whole application (or sub-application)

The page is smallest unit. The related pages are not arbitrary: you can't have a search page without a results page. The "whole application" is somewhat arbitrary.

When you add functionality to a web site, it is usually done in chunks of "groups" of pages. Programmer responsibililty is frequently at the group level. Your "code orthogonality" is likely at the group level. So my conclusion is that right granularity for managing an application is at the "group of related pages" level. I usually have a perl script for each such group.

I'd be curious to hear from people who used CGI::Application or similar for small, one-person tasks and find out what happened when the size of the project and project team grew substantially.

---

---

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.