Sebastian, John,
thanks for your response. From what I understand, there are ways AROUND,
but there is no DIRECT way to do this using CGI::App. To me it seems that
having to use 'redirect' for this purpose is no better than having a bunch
of linked plain *.cgi scripts. It defeats the whole purpose of CGI::App.
Using a selective 'require' may work fine, but it seems more like a patch
to me too. I am considering using CGI::App with FastCGI, which
precompiles the code and serves it from the memory. I am not sure if
'require' will work in this case, since 'require' is run-time compilation.
Just received Darin's e-mail.
I think, it is better to improve the existing module than to create a new
one. The problem, in my opinion, is the requirement that the methods in
MyCGIApp have to return output, rather than produce output themselves.
Without this restriction, there would be no problem with running other
CGIApp objects from methods within MainCGIApp. Does anyone know the
reasoning behind this requirement?
Arkady.
On Wed, 26 Mar 2003, Seb wrote:
> On Wed, 26 Mar 2003 08:05:06 -0800 (PST), Arkady Grudzinsky <[EMAIL PROTECTED]>
> spoke gently:
> > Hi, everyone.
> >
> > Assuming my application consists of several independent
> > "sub-applications", is it possible to initialize and run CGI::App objects
> > for these sub-applications from within the MainCGIApp.pm or do I have
> > to create independent applications and link them including 'redirect'
> > statement in the MainCGIApp.pm? If I run another
> > object inside one of the methods, the output, of course, is doubled.
> >
> > What is the best way to deal with this?
> >
> > Thanks.
> >
> > Arkady.
>
> I encountered a similar dilemma. I wanted to create 'sub-applications',
> or 'modules' of a larger application framework. This as you know is
> easily solved by subclassing C::A, putting system-wide methods into your
> subclass, and then building sub-app modules that inherit from it. You're
> already doing this, if I'm not mistaken.
>
> However, I also didn't like all the nearly empty initialization CGIs
> sitting around, and having to link around between them. I do, in some
> cases, use a single-file approach to C::A apps:
>
> package MyCGIApp;
> use base CGI::Application;
> # some code...
> # ...
> # at the end...
> package main;
> my $app = new MyCGIApp;
> $app->run();
>
> But for this system, I wanted wanted just one URL to access the system,
> regardless of what component/module the user needed.
>
> My solution involves one index.cgi that knows what 'modules' there are
> in the system, and loads one depending on a CGI parameter that is passed
> around. In this simplified example, I have a directory structure...
>
> ./MyApp.pm (master package, inherits C::A)
> ./index.cgi (loader)
> (sub-app packages, each is a 'standard' C::A, inheriting from MyApp.pm:)
> ./MyApp/Main.pm
> ./MyApp/Jobs.pm
> ./MyApp/Parts.pm
> ./MyApp/Reports.pm
>
> And index.cgi looks something like this:
>
> #!/usr/bin/perl
> use CGI;
> my $q = new CGI;
>
> # $modules contains the list of params that are accepted for 'mod'
> my $modules = {
> main => 'Main',
> job => 'Jobs',
> part => 'Parts',
> report => 'Reports',
> };
>
> # Get the needed module, if any
> my $mod = $q->param('mod');
>
> # Sanity check and set default
> unless ($modules->{$mod}) {
> $mod = 'main';
> }
>
> # Load the module
> require "MyApp/$modules->{$mod}.pm";
>
> # Make/run an app object
> my $app = "MyApp::$modules->{$mod}"->new($q);
>
> $app->run();
>
> __END__
>
> I think it works rather nicely.
>
> -Sebastian
> What draws us into the desert is the search for something intimate in the remote.
> -Ed Abbey
>
>
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
