[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cgiapp
Subject:    Re: [cgiapp] Splitting large projects.
From:       Brian.T.Wightman () jci ! com
Date:       2004-04-09 13:46:36
Message-ID: OF39EBAF68.416A26E9-ON86256E71.0049F804-86256E71.004BAD76 () jci ! com
[Download RAW message or body]





Instead of using "mod". you could use the name of the CGI script as your
"mod", and then "rm" is specific to the cgi.  I would include my common
code from a "SuperApp", and have instance CGI scripts, <CODE>use</CODE>ing
the appropriate module (rather than requiring it, as in your code).

One benefit of this approach is that you can use the security mechanisms of
the Web Server to manage access to the individual cgi scripts, rather than
having to get it right in your own code (build on the work of others, don't
reinvent the wheel, blah blah blah).  I would rather trust the security
interface built into Apache, rather than having to validate my own, and my
background is in security.

But, as often happens in Perl, TIMTOWTDI (There Is More Than One Way To Do
It).

Brian
--
Brian T. Wightman                brian.t.wightman@jci.com
Global Data Management          http://pdm.cg.jci.com/
Johnson Controls, Controls Group          (414) 524-4025


                                                                                      \
                
                      mheight@iinet.net                                               \
                
                      .au                      To:       cgiapp@lists.erlbaum.net     \
                
                                               cc:                                    \
                
                      04/09/2004 06:45         Subject:  Re: [cgiapp] Splitting large \
                projects.                                             
                      PM                                                              \
                
                                                                                      \
                
                                                                                      \





I have a single CGI script that handles every request to the application.
The CGi parameters 'mod' and 'rm' select the module to be executed and the
method within
that module respectively.
I am interested in knowing what others think about this approach.
A skeleton of my code looks like:


#!D:/Perl/bin/perl.exe
use strict;
use CGI;
use CGI::Session qw/ -ip_match/;

# Define the modules used by the application
my $modules = { session => 'Session',
                modA    => 'ModA',
                ....    => '....',
                modX    => 'ModX',
              };

# If the client is logged on, use the requested module, otherwise force a
logon
my $mod;
my $query   = new CGI;
my $session = CGI::Session->new(undef, $query, { Directory => 'some_dir'
});
if ($session->param('is_logged_on')) {
    $mod = $query->param('mod');
}
else {
    $mod = 'session';
    $query->param('rm' => 'logon_expired') unless $query->param('rm') eq
'logon';
}

require "../modules/$modules->{$mod}.pm";

# Create and run the selected app module
# $app is an instance of a super class of CGI::Application
my $app = "$modules->{$mod}"->new(TMPL_PATH => '../Templates/',
                                  QUERY     => $query);
$app->run();



---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@lists.erlbaum.net
For additional commands, e-mail: cgiapp-help@lists.erlbaum.net





---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@lists.erlbaum.net
For additional commands, e-mail: cgiapp-help@lists.erlbaum.net


[prev in list] [next in list] [prev in thread] [next in thread]