Warning: Stream of consciousness below
> > (Simple version)
> OK, this would work, but wouldn't EvaluateAction() just be a big
> if-then-else tree? (sort of what I am trying to avoid with cgiapp)
Yup. To fix that, use the Vaughn::App.
> > (More complicated but more flexible version)
>
> I tried something like this, but aborted it. I was trying to
> handle the action routine in the subclass run() and then call
> run() in the base class to handle the screen. As you suggest it,
> I should override run() in the base class altogether. Hmm ...
I can't really see any other way around it. You want a routine that is
both completely independant of the screen mode, and could theoretically
change the parameter that selects the screen mode (here I'm using screen
mode == CGI::App run mode).
Looking at the code, you might have your sub-class create a new routine,
call it....jog. jog() is called by your instance scripts. jog() calls
action() and run(). action() works just as run() does, without the output
sections.
That way, your run() will inherit any upgrades in CGI::App.
Of course, I'm not a Perl master, so take all of this with a grain of
salt.
> As a final question, given that "a problem with the single Run
> mode param is probably the most FA of the FAQs" are there any
> proposals being considered to support something like a list
> of run mode params in the future? Controlling the output would
> obviously be an issue, as it is for me currently.
Most often the needs of people aren't the same. The appeal of CGI::App is
in it's simplicity. Most people seek to have more than one parameter
determine run-mode, this is the first I've seen of multiple fuctions based
on different mode-params (though I've only been on here a few months).
> I'm still not sure I understand why it is necessary for run()
> to do the print. Since it returns $output(), wouldn't it be
> more flexible to let the programmer decide what to actually do
> with the output that run() produces?
I'm inclined to agree with you, except that I wouldn't want to reduce the
current ease CGI::App has.
Looking at the code again, I see inside run():
# Set up HTTP headers
my $headers = $self->_send_headers();
# Build up total output
my $output = $headers . $body;
# Send output to browser (unless we're in serious debug mode!)
unless ($ENV{CGI_APP_RETURN_ONLY}) {
print $output;
}
# clean up operations
$self->teardown();
return $output;
}
So in theory, that print statement could be axed, and control could be
given to the instance script. THat would only change the normal instance
script to "print $MyModule->run();"
But that wouldn't really help you, because you're still bound to a single
run-mode.
UNLESS...Your instance script called two application modules. You could
then decide what to do with it. Something like:
#!/usr/bin/perl -wT
use strict;
use MyActionModule;
use MyScreenModule;
my $actions = MyActionModule->new();
my $screens = MyScreenModule->new();
#Do action
if($actions->run()){
#Output screen
print $screens->run();
}
Hmm. Except that data wouldn't pass naturally between the two modules,
you'd have to put processing in your instance script. Or wrap all of it
inside ANOTHER call to CGI::App, and have the handling inside that
application module, but then I think we're getting ridiculous. Since you
have a clearly defined goal, you're probably best off trying something
similar to the Vaughn::App I described above, with one run mode param
(screen mode) and one action param. All IMNSHO, of course.
Jesse, we're talking some fundamental concepts here, you want to throw in
some guidance?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
