> 3. An OO module with a wrapper interface
>
> [ I'm still evaluating this approach and would like to feedback on the
> idea. ]
>
> The problem here is that you want to write a related custom OO module,
> but you want easy access to a number of parts of your CGI::App object
> such as the database handle, configuration settings, session information
> and the query object.
>
> There are a couple parts to this problem:
> A. It would be a pain to pass all 4 of these elements to an object
> constructor each time, and making them global variables would only
> make things messier. (I've tried that!).
>
> B. You want easy access methods for the session, database handle, and
> config variables, like the CGI::Application plug-ins can provide.
>
> Here's one idea for addressing "A", the constructor issue. Let's say
> we've got a skatepark object. We may want a constructor that looks like
> this:
>
> my $sk8_obj = Skatepark->new( id => 29 );
>
> We pass in the extra information we want automatically by using a
> wrapper method:
>
> my $sk8_obj = $self->init_skatepark( id => 29 );
>
> The wrapper would simply pass additional info into the constructor.
> This keeps the Skatepark object independent of CGI::Application,
> allowing it to be easily re-used by other front-ends. Our wrapper
> method might look like this:
I'm currently using a system like this for all my applications.
I've got a simple module called Environment.pm. It controls access, loading,
parsing etc for DBI / Session / Config / CGI. Each instance script creates
an environment object first and then passes it to the CGI::Application. My
CGI::Application Base Class has a function called env() which will either
store or return the environment depending on how it's called.
What it translates into in code is that instead of calling $self->query(), I
now call $self->env->query() or $self->env->dbi() or $self->env->config(),
etc.
When I write plug-in modules they also have their own base class called
Skeleton. The Skeleton module also has an env() function that works the same
was as the env function in the CGI::App base class. So when I load a new
plug-in module the very first thing I do after creating the object is call:
$newobject->env( $self->env );
Now $newobject has access to the same environment information that my
CGI::App object has. To avoid forgetting to load the env every time I load a
plug-in, my Environment object keeps track of which custom plug-in modules
the application has access to and assigns a name to each one, so if I want
to call my plug-in module that accesses a Pop3 box, instead of writing:
use Application::AccessPop3;
my $pop3obj = Application::AccessPop3->new();
$pop3obj->env->( $self->env() );
I call
my $pop3obj = $self->env->loadobj( 'accesspop3' );
The loadobj() function takes care of locating, loading and passing the
environment to the Application::AccessPop3 module, and returns me the object
I need. Now, inside of $pop3obj() I have access to $self->env->query() /
dbi() / config(), etc.
As an added bonus to this if I'm writing cron scripts, as long as the proper
environment is loaded I can access all the same plug-in modules during a
cron run as I can during a CGI::Application call. However, in order for this
to work properly, I try to access the $cgi & $session objects as little as
possible (if at all) in any of the plug-in modules that could be run from a
cron as well as a cgiapp as obviously when running via a cron there will be
no cgi or session to speak of. But having access to the dbi / config and a
couple other important functions in there sure helps.
Granted it's a fairly complicated relationship and has a bit of overhead
associated with it, but I've found that over the last 2 years that I've been
writing applications in this format I've been able to split up my
applications in a logical fashion and always had access to the information I
need without having to worry about how / where a plug-in module loads config
/ dbh / etc. I know the system isn't perfect, and there are probably a
number of improvements I could make to it, but it works for me, for now and
most of the time that's the important part :)
Just for added clarity, here's what my instance script now looks like:
# required modules
use Application::Environment;
use Application::ShoppingCart;
# create the application environment
my $environment = Application::Environment->new
(
'params' => 'go here',
'like' => 'config_file_name',
'or' => 'default_cookie_name_for_sessions'
);
# load the web application
my $webapp = new Application::ShoppingCart;
# add environment to web application
$webapp->env( $environment );
# run web application
$webapp->run();
---
Steve Comrie
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
