I work in a small team using CGI::App, and our basic class structure looks something like this:

• Superclass (rarely modified)
  • Utilizes classes for:
    • authorization/authentication
    • templating
    • site customization (in our case, different sites may need slightly different sitewide behaviour; we handle this through a plugin system)
  • Inherited by Application Class: calls:
    • API class(es) (for business logic)
    • Form handling class (for form validation and error handling) -- if necessary
      • Utilizes a config file
    • templates

The point of the above outline is this: sure, each run mode is a method in the application class, but generally speaking, the application class is but a small part of the project. The API(s) associated with the application are typically much larger (as they handle database calls, mail notifications, logging, etc.). While CGI::Application itself is a very small module, and provides a simple, flexible, framework, when you get into a site of any size, a much larger ecology of code develops. Each developer works in the area in which they are most comfortable: templates (designer), APIs (DBA or SA), application (web developer), etc. And then juggle positions every now and then to add spice.

Additionally, as perrin noted, if you're using a source code versioning system, you really should have few if any conflicts when working on the same application class. If each person were working on a single run mode, any commits to the tree could be easily merged with earlier commits as they would not be touching the same code -- each person would be working on separate methods of the class.

On the subject of APIs, I find that I typically like to write them such that I can pass some minimal information from my controller (application class) to the API, receive some data, and then pipe it into a template. If done correctly, this amounts to about two lines of code in the application class -- which makes the application class very easy to follow.

On the subject of application classes, remember the rule of thumb: if you get more than 7 run modes going in your application, you probably need to start thinking of dividing your application into multiple applications. When you get that many run modes, the class gets unwieldy to debug and maintain. This is particularly true in team environments -- any one of you may need to maintain the class in the future, and if it's too difficult to follow, nightmares, castigation, and finger pointing start to ensue.

A CGI::Application is, as you note, a controller. It's intended to determine the page flow of an application. As such, I find that if my APIs and superclass are well written, a good, clean application class ends up being incredibly sparse, and more like an outline of what happens when. You then go into the called classes and methods to determine the details.

So, in summary: your team will have a plentiful division of labor with a good CGI::Application framework.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.