laziness, impatience, and hubris | |
PerlMonks |
Re: CGI::Application in a team development environmentby weierophinney (Pilgrim) |
on May 26, 2005 at 02:06 UTC ( [id://460485]=note: print w/replies, xml ) | Need Help?? |
I work in a small team using CGI::App, and our basic class structure looks
something like this:
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 Section
Seekers of Perl Wisdom
|
|