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.

This concept is in opposition to "Server-Page" systems which "homogenize"
every run-mode into a separate file, or monolithic "Mega::Application"
modules which contain every run-mode in your site -- which is effectively
the same thing as in a Server-Page system.

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.

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.

This is not to say you can't have a large body of code which is shared
between modules!  At VM we often have constituent "helper" modules which
contain methods which are used by many -- often ALL -- CGI::Application
modules on a site.  (These types of modules are sometimes referred to as
"Model" modules by M/V/C purists.)  In our architecture, the CGI-App modules
often are fairly small, relying on the "helper" modules to perform much of
the heavy lifting and business logic.

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.  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.


IMHO,

-Jesse-



  Jesse Erlbaum, CTO
  Vanguard Media
  http://www.vm.com
  212.242.5317 x115
  [EMAIL PROTECTED]





---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/[email protected]/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to