On Fri, 24 May 2002, Brett Sanger wrote:
I've missed the beginning of this discussion, so just tell me to shut
up if I'm off track here.
Yeah, you're off track. We're not talking about setup()...
If you have the run-mode name in a variable you can do:
my $run_mode = foo;
return
Yeah, you're off track. We're not talking about setup()...
Okay, I withdraw my complaints :)
2) Is discouraged, because 90% of soft-references should be hash elements?
That still leaves a healthy 10% for this and a few other usages.
I see the healthy 10% as areas that are controlled,
On Thu, 23 May 2002, Cory Trese wrote:
I know, I know. I've been wondering how I missed this for so long ...
it has made developing web applications fun again!
Yes, really!
The 2.3 release does not provide this functionality, AFAIK. However, that
doesn't mean 'cgiapp_prerun( )' or
I know, I know. I've been wondering how I missed this for so long ...
it has made developing web applications fun again!
Yes, really!
And my application reuse has gone up astronomical amounts!
The 2.3 release does not provide this functionality, AFAIK.
However, that
doesn't mean
On Thu, 23 May 2002, Cory Trese wrote:
Are those run modes or operations leading up to the run-mode?
They are real run modes.
Is this something you can handle by passing it off to your error handler
instead of trying this run-mode magic? Changing (or redirecting) to a run
mode to handle
Lets stimulate discussion!
We have two types of patterns that I see : (1) redirecting a user during
initialization, (2) after another run_mode is done, or has decided that it
cannot provide additional progress for the user without intervention from
another run_mode.
It would be very nice to
At 03:03 PM 05/06/2002, Jesse Erlbaum wrote:
The cgiapp_prerun() provides an important hook, but it is still a
bit limited. One thing it does not yet do is provide a facility
through which you can modify the run-mode. After I made the
release, it occurred to me that changing the run-mode
First off: Is being able to change the run-mode as important as I suspect
it is? If not, no further changes are required.
It is important, within the current scope of relativity (i.e. Its good to
have if we have a cgiapp_prerun() method)
I'm inclined to use the return-value method, but
What about having $self-current_rm() as an object function instead of
passing it around into and out of sub-routines?
then you could get the rm:
my $rm = $self-current_rm();
and change the rm:
$self-current_rm( $rm );
===
steve comrie :: senior developer
http://www.shrinkingplanet.com
-
I would vote for the return value, since it is similar in behavior to the
run-modes within CGI::Application.
my $0.02,
Brian
[EMAIL PROTECTED] on 05/06/2002 02:03:34 PM
To:[EMAIL PROTECTED]
cc:
bcc:
Subject:[cgiapp] cgiapp_prerun() method
[snip]
1. Return run-mode value
2.
What about having $self-current_rm() as an object function instead of
passing it around into and out of sub-routines?
then you could get the rm:
my $rm = $self-current_rm();
and change the rm:
$self-current_rm( $rm );
I like this idea, but it could get more involved. I currently have
Hi Steve --
What about having $self-current_rm() as an object function instead of
passing it around into and out of sub-routines?
then you could get the rm:
my $rm = $self-current_rm();
and change the rm:
$self-current_rm( $rm );
This is the same problem as
12 matches
Mail list logo
