Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

CGI::Application in a team development environment

by jeyroz (Monk)
on May 25, 2005 at 15:13 UTC ( #460349=perlquestion: print w/ replies, xml ) Need Help??
jeyroz has asked for the wisdom of the Perl Monks concerning the following question:

I have been researching the benefits of using CGI::Application to handle run modes in web applications. I, however am unclear on the development process when using such a tool in a TEAM environment. It seems to me that because the application logic, (& "Run-mode Methods") are all kept in an single file - an "Application Module", developing such an app in a team environment would be tricky. Any custom classes for the application could be developed separately but the controling logic for the entire app is still in one file. Does anyone out there have experience using CGI::Application in a team env?

Any thoughts and advice would be helpful.
Thanks.

author => jeyroz

Comment on CGI::Application in a team development environment
Re: CGI::Application in a team development environment
by perrin (Chancellor) on May 25, 2005 at 15:23 UTC
    • Having multiple developers work on a single file is only a problem if you have no version control, or are making massive changes.
    • A well-written CGI::Application module would not have much in the main class. It would be calling other classes to do most of the work. The main class just translates web requests into method calls on other classes.
    • Any project large enough to have a team working on it will have multiple CGI::Application modules. I like to split things up into logical "applications" so that if Jane is working on the address book app and Jim is working on the calendar, those will be separate modules.
    • In practice, I've never had a problem with teams using any kind of MVC approach like CGI::Application.

      My experiences with CGIApp are very much in line with what perrin's is stating. If you break up your runmode modules into logical tasks, you will end up with a whole bunch of modules with only about 3 or 4 runmodes in each. If you start noticing that you have 10 - 15 runmodes, then perhaps you should think of break this into smaller pieces.

      One thing that some users find annoying about breaking the application up into smaller pieces like this is that you require a small CGI script for each of your runmode modules to fire up the application. We have found that using the CGI::Application::Dispatch module really simplifies this by having a single CGI script (or mod_perl handler) that can spawn multiple runmode modules based on the PATH_INFO of the request.

      Also, I find that most of the logic in any of the larger CGI::Apps I have built tends to fall into the Model of the application. Most of the runmodes tend to be quite simple and generally just pass data between the Model and the View, with a bit of data validation thrown in.

Re: CGI::Application in a team development environment
by dragonchild (Archbishop) on May 25, 2005 at 17:45 UTC
    In any web application bigger than a toy, the C::A classes are going to be less than 20% of the actual code. The rest of the work should be done in business-layer classes. For example, I have a C::A reporting application. The reports are defined in their own classes. The C::A stuff has 2-3 runmodes that dispatch to the appropriate report class. C::A - maybe 200 lines. The reports, parameters, and templates - 2000++ lines.

    If you decompose correctly, you shouldn't be working in the C::A hierarchy unless you're changing user interactions.


    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
Re: CGI::Application in a team development environment
by astroboy (Chaplain) on May 25, 2005 at 18:30 UTC

    As dragonchild pointed out, your main business logic (model) can be in separate modules/packages to your rum modes (controller)

    In addition, you'd split your runmodes up across many packages. You might have your content package, your shopping cart package, your user maintenance package. So really, there shouldn't be too much contention for the application files among your developers.

      your main business logic (model) can be in separate modules/packages to your rum modes (controller)

      I've tended to think of the model as business objects, and the run modes as business logic. If I want to change the way the application flows, I change the logic in my run modes (business logic). If I want to change the people, places, and things in my app act I change the model (business objects).

        I guess it comes down to how you conceptualise things in your application environment. I tend to think as model as both business object (e.g. customer) and the rules and interactions that the object can undertake (kind of analogous to a programming object being both the data and the methods for manuipulating the data).

        In my run modes, I either simply pass user input to the model package (after validating with the ValidateRM plugin), or I generate the output using HTML::Template. I used to have a bit more logic in my runmodes, but I've found that keeping them minimalistic and moving everything involving db access or business rules to other packages has made things leaner and easier to maintain

        However, my apps don't tend to have complex application flows (e.g. you enter content or you update content), so maybe the logic/object separation works well for you. Anyway, I believe the MVC definitions aren't especially rigid - but some people tend to take religious positions defending their particular framework/point-of-view, but I don't find that particularly useful

Re: CGI::Application in a team development environment
by brian_d_foy (Abbot) on May 25, 2005 at 21:50 UTC

    The trick is to figure out which parts of the system going into which part of the MVC (Model-View-Controller). In my experience, most of the work ends up in the Model part, which doesn't really care why or how you are looking at it. It's general code to do all of the interesting work without thinking about how you actually look at the data or how you tell it what you want to do. Above that is code to take those results to show it to us (the View) and other stuff to let us make it do things (the Controller). The V and C portions really aren't all that tough: they translate our requests into things the model can do, the translate what the model did back to our environment. They are really just adapters between our application and the Model.

    Things don't end up in a single file because the idea is that there is no monolithic application. The Model should be able to use any View or Controller. It's not just a web application because it could be a SOAP thing, or a terminal interface, or something else. The Model should exist separately from a particular use of it.

    Once those things are decoupled, people can work on the different layers and different parts without colliding with each other.

    --
    brian d foy <brian@stonehenge.com>
      Newer MVC approaches like Catalyst and Ruby on Rails put more logic in the Controller (they support multiple controllers) than the classic ones, which results in a more balanced architecture.

      Oh yes, and i suggest SVK for teamwork.
Re: CGI::Application in a team development environment
by weierophinney (Pilgrim) on May 26, 2005 at 02:06 UTC
    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.

Re: CGI::Application in a team development environment
by tphyahoo (Vicar) on May 26, 2005 at 11:40 UTC
    perrin mentioned the necessity of version control in a team environment, with which I wholeheartedly agree.

    If you're not already using version control, have a look at subversion. It's the bomb.

      I want to thank everyone for their comments ... much appreciated. I wrote my first C::A this week and am very happy with the structure and flow.

      author => jeyroz

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://460349]
Approved by holli
Front-paged by Tanktalus
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (15)
As of 2014-12-26 16:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (172 votes), past polls