"William McKee" <suppressed> wrote (in part): > Jesse, thanks for the recap on your philosophy of CGI::App. I'm still > experiencing growing pains from moving beyond simple cgi scripts to full- > blown web applications that entail several components and multiple > interfaces. I'm beginning to see how to write my scripts using your > approach but have had to struggle with it. > > I think one mental problem I'm having is that I want to eliminate code > redundancy. However, it seems your philosophy would say that if there is > an admin interface to the data and a user interface, there should be two > separate CGI::App modules to implement these separate interfaces. That > seems like redundancy. if by "redundancy" you mean "code copied and pasted" into multiple CGI::App modules, that's not necessary, at all. i agree with Jesse that it's a good idea to maintain a one-to-one correspondence between instance scripts and CGI:Application modules, but that doesn't mean that two (or many more) CGI::Application modules can't share code using another (non-CGI::App) module, that implements common functions needed by several different scripts. i think perhaps the word "Application" being in name of the module leads some programmers to expect that CGI::Application is designed to encapsulate a very large number of operations than if Jesse had named it, say, "CGI::ScriptOrganizer" :-) thinking of Windows "applications", for instance, conjures images of a large programs with hundreds of screens, options dialogs, and submenus within each. having built a few sites with multiple CGI::Apps (some public, some administrative) i've pretty much adopted this "shared module" approach as the rule, not the exception. taken together, these separate but tightly integrated CGI::Apps and the shared modules they reuse could be considered a CGI::Application suite :-) there's a couple of approaches to deciding what should be in such a shared module. one approach is to simply create a module as the "paste-target" to use whenever you feel the temptation to *copy* code from one CGI::App into another. that way you can *cut* and paste into SweetsForTheSuite.pm, add "use SweetsForTheSuite;" to both modules, and call the functions from everywhere you need them, instead of copying them (and having to maintain them) in multiple places. i think of this as the "Library" approach, because you tend to end up with a module with various miscellaneous library functions, mostly unrelated to one another but used in, and needed by, various apps. another approach is to encapsulate all the functionality that is *not* CGI-related or even web-related, into more abstract modules. say you have a CGI::App module that administrators use to manage users via the password-protected intranet, and another that lets anonymous visitors search for a user's email address, but you also have a system-invoked, regularly scheduled cron job which automatically expires users who haven't paid their dues, and a bounce-detection script, invoked by a qmail filter, that disables users whose emails are bouncing. in such a situation it makes lots of sense to have an abstract My::Users module that is not specific to CGI's, cron jobs *or* mail filters at all, but rather it houses high-level utility functions relating to Users. these other apps (CGI and otherwise) all call to do all their actual User-related dirty work. when you break things up like this, any and every application that cares about users, should be doing so via this module, so that the day your Users database is upgraded to Oracle, downgraded to flat-files or migrated over to a remote LDAP server, you can rewrite My::Users, and (hopefully) all the apps will seamlessly and transparently get the upgrade. well, maybe that's more the theory than the practice, but it does make your CGI::Apps much smaller when you separate the code so that "code that processes CGI input" and "code that generates HTML output" is in your CGI::App, but "code that creates, reads, updates and deletes users" lives in My/Users.pm in the Model-View-Controller paradigm, MY::Users in this example contains the "Model" methods. you may now commence arguing amongst yourselves where, within a CGI::App that uses HTML::Template, the "View" methods end and the "Controller" methods begin :-) -dave --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/suppressed/ 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.