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.
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
