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/[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]
