At 01:00 PM 04/03/2002, Jesse Erlbaum wrote: >Hey Greg -- > > > At 11:36 AM 04/03/2002, Jesse Erlbaum wrote: > > >Does this describe your situation? If so, why don't you simply > > >break your application into multiple applications, by required > > >authority? Each application could then have its own instance > script. > > > > At this point, you've lost much of the power of CGI::App, because > you > > have to divide your application into different parts based on what > > possible access groups you might have in the future. > >I don't agree. Judiciously scoping application modules is one of >the cornerstone concepts in CGI::Application.
While that's true, I just don't see access groups as a good method to use for this scoping. The access control can often be totally unrelated to anything else in the application. >CGI-App is based, in no small part, on the idea that an application >is a collection of related run-modes. "Related" may be based on >similar function, or similar required credentials. Properly scoping >your application modules is part of the "art" of being a good >CGI::Application developer. I prefer grouping based on function over grouping based on required credentials, especially when the required credentials part is more fluid, and it is simpler to change the credentials for a run mode than it is to move that run mode to a different application. >Scoping your app modules always involves asking yourself where one >application module should end, and another one begin. This needs to >be based on specific interface design. You can't do it from 20,000 >feet. The decision needs to be based on how the modules are used, >and by whom are they used. However, when the "by whom" can change often, and the "access groups" have to be broken up and rearranged, you can either be helped by your access control logic, or hindered by it. I'd much rather change the access control in the mode than have to move the run mode to a different application and then have to change everything that refers to it. Moving run modes from app to app also makes it much more difficult to follow the revision control history of the application. >We're find of saying here, that "life does not end at version >1.0". It is always necessary to re-factor applications to update >them for unforeseen use. Absolutely. I'm on version 5 (at least) of this system, which was originally written as a text-based command line application back in 1995. Since then, it's been rewritten as a combination text-based, Motif-based app, had a web interface added, and now totally redesigned and rewritten in CGI::Application/MySQL. >There have definitely been times when new functionality (a feature, >or a new security delegation) has required us to move a run-mode >from one application module to another. Through the proper use of >modularization via helper modules, this task can be made to have a >minimal cost. It is, in fact, the natural evolution of any software >system. That's true, and you can either design things so that it is easy to change the security delegation, (higher short-term cost, lower long-term cost) or you can design things so that it is easy to write the security groups now, and difficult to change them in the future (lower short-term cost, higher long-term cost). The one place where I've split the application based on access control is one portion of the application that will always be open to the public. In this case, I have one application/instance script that doesn't use authentication, and one that does. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning" --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
