I work in a small team using CGI::App, and our basic class structure looks something like this: 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.

In reply to Re: CGI::Application in a team development environment by weierophinney
in thread CGI::Application in a team development environment by jeyroz

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • 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! —
  • 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:
    & &amp;
    < &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.