Re: [cgiapp] Good practices: how many run modes in an app

[Brad Cathey <suppressed>]

Thank you Michael, that was very helpful. Unfortunately it uncovered areas
I'm unfamiliar with, that a good study of OO will help.

> 
> Brad Cathey wrote:
>> I'm writing a medium-sized web-based financial application that will have up
>> to 50 run modes between presenting empty forms, saving, editing, updating,
>> and deleting from them. Run modes *could* be broken down into groups, e.g.,
>> these 4 deal with managing users, these 6 deal with managing project
>> specifications, etc.
> 
> 
> 50 is definitely too much. There isn't a hard rule to follow for what is too
> much, but I think there can never be too few. I usually split them up by
> functionality or user authentication level. And remember that base classes are
> your friend here. For instance, if I have admin and normal users and each can
> view reports. Some reports are the same, but some are different, I would split
> them up into the following structure:
> 
> MyApp::Base       - base class for all my app classes that might have classes
>       to deal with configuration, database, sessions,
>                        templates, etc that they all have in common.
> MyApp::Report       - base class for reports that contains those reports that
>                        everyone can see as well as common methods used to
>                        generate reports, graphs, etc
> MyApp::Report::Admin - app class containing admin reports
> MyApp::Report::User  - normal user reports
> 
> Most of it is personal perference, but you really need to break it into
> structures.
> 
>> Being new to C::A I'm curious if there are any general rules of thumb as to
>> the number of run modes (subs) that are run in any given Appl.pm. Besides
>> the long list under setup, there might be performance issues, and places
>> where trying to use a common sub might get messy.
> 
> I think the keyword here is 'messy'. OO programming in general is not about
> speed. It's almost always slower to use an OO approach, but it's very useful
> for
> organization. No matter what you write, you are always going to be making
> changes and adding new stuff. The better organized and cleaner it is, the
> happier you (and the person after you) will be.
> 
>> In my pre-C::A days I would have been more inclined to break it down into
>> various scripts, maybe by function. But I'm not sure of how this fleshes out
>> in a C::A world.
> 
> I'd follow the same kind of approach that you used to have. The advantage of
> the
> C::A world over using multiple scripts is inheritance. Break common
> functionality and common run modes out into base classes and you will be much
> happier.



---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed