I agree wholeheartedly with Mark. I've found this very helpful.
A discussion and some examples of the base and apps classes in use would be
great as well.
Brad
>> 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.
>
> This is a FAQ that there should be a page about on the wiki if there is
> not already. Michael's answer is a great start.
>
> Anyone want to work on this? http://www.cgi-app.org/
---------------------------------------------------------------------
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
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.