>I am starting a new project today which is going to have more 200 run
modes, and I would
>like to break things up.
>But I'd like to have single CGI script that handles every request to the
application.
>I also need to have centralized list of all run modes from every module.
>I'm going to have some kind of config where to store all run modes with
information
>where every sub is located, something like this:
>#run-mode:module:sub
>1:Module01:hello
>2:Module01:show_some_form
>3:Module02:show_another_form
>4:Module03:do_something
>Which means if we call script.cgi?rm=2, sub show_some_form() from
Module01.pm should
>be executed.
>Next. I suppose I will have one base class which will be called form CGI
script.
>This class will have only one run-mode, which will load config and
determine, which
>module to and which sub to execute.
==============================
Echoing prior responses:
- 200 run modes does sound like too many if this is a single application
(i.e. sales web site). If you're building an accounting system (ooph!)
with real user modules (i.e. chart of accounts, accounts payable,
accounts receivable) then 200 isn't unreasonable. However, SQL has only
4 "run modes" (select, insert, update, delete) and it seems to work
rather well.
- mod_perl may help improve runtime, especially if you have a lot of
concurrent users. Otherwise, garbage collection afforded by PERL
is a nice feature for some of us. 2,000 line PERL files load and run
pretty quickly.
- Avoid anything that involves turning off "strict" -- especially with
a large application! Namespaces get polluted very quickly and debugging
becomes impossible, for one reason.
The scheme below breaks the structure an application into smaller modules.
The scheme can be applied to apps without a RDBMS.
Three modules:
My_app.pm
My_app/DB_handler.pm
My_app/SQL.pm
This keeps:
the run modes in one module,
the subroutines in a second module,
the SQL queries in a third module.
Run Modes end up as a few lines and the application control is in just one
module, making maintenance and debugging easier.
My_app.pm
-----------------
package My_app;
use base 'CGI::Application';
use DBI;
use My_app::DB_handler;
use strict;
.....
------------------
DB_handler.pm
------------------
package My_App::DB_handler;
use My_App::SQL;
use Class::MethodMaker;
use strict;
.....
------------------
SQL.pm
------------------
package My_App::SQL;
use strict;
.....
------------------
Pass objects (i.e., $dbh) created in My_App.pm to the DB_handler.pm.
MethodMaker re-creates all the methods for those objects.
SQL.pm is a file of subroutines.
sub email_select {
return <<QEND;
select email_address from user where user_id = ?
QEND
}
FWIW: Two additional benefits are:
1) you can run / debug individual SQL queries in this file
from the command line,
2) parameters are bound to the query, rather than passed,
lessening / eliminating the chance of buffer overflows.
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
|
