>
> I apologize for replying on-list, but having just released 2.3,
> I'm about to
> suggest something which may very well necessitate a 2.4 release tonight,
> before anything important is built on top of 2.3.
No problem. Thanks for leaving out the embarrassing parts *wink*.
> 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 based on some other logic would be
> useful. That
> might allow you to put a dynamic switch in-line which is
> triggered based on
> some other logic. For instance (to modify my earlier example):
I love this idea.
> This is a pretty different interface from the cgiapp_prerun() in
> 2.3. I'm a
> bit nervous about using return values because failure to return
> the run-mode
> would totally break the app. (Maybe that's OK?) This raises the
> bar a bit
> for anyone who would like to use cgiapp_prerun() for adding a
> behavior which
> would NOT change the run-mode. (Now, they HAVE to return the run-mode, or
> else!)
When you say 'totally break the app' what exactly do you mean? Empty
return?
General Page Fault? Un-changed run-mode?
I am personally ok with this. If we forget to return $output (or whatever
you people
call it) we totally break the app.
> Two other possible interfaces are using a special param, 'CGIAPP_RUNMODE',
> or using a scalar-ref.
>
> The param interface might look like this:
>
> sub cgiapp_prerun {
> $self->param("CGIAPP_RUNMODE" => "show_login_form");
>
> The problem here is that this "special param" would only have an effect if
> changed in the cgiapp_prerun() method. While you *could* change it
> anywhere, only in cgiapp_prerun() will it actually change what run-mode is
> called. Kind of deceptive and confusing.
I agree and dislike this, probably just like everyone else.
>
> The scalar-ref interface might look like this:
>
> sub cgiapp_prerun {
> my $self = shift;
> my $ref_run_mode = shift;
>
> unless ($self->is_user_allowed($$ref_run_mode)) {
> $$ref_run_mode = "show_login_form";
> }
> }
>
> The upside of this is that it doesn't put the onus on every developer to
> return a run-mode even if they are not changing it. The problem is
> two-fold: First, the current interface already is documented as
> passing in
> a scalar -- not a scalar-ref. (Since the release was just made
> today, this
> is probably not a big deal since no code was yet written to use a scalar.)
> The second problem is that scalar-refs, like all refs, are thorny to work
> with. Most Perl programmers are uncomfortable with this type of "C-style"
> interface.
If you ask me, this is more deceptive and confusing than the ->param driven
method.
>
> So, it's decision time!
>
> First off: Is being able to change the run-mode as important as I suspect
> it is? If not, no further changes are required.
>
> If changing the run-mode is important (as I suspect it is), than what
> interface suits the list members best? We have three options:
>
> 1. Return run-mode value
> 2. Set special param, 'CGIAPP_RUNMODE'
> 3. Modify scalar-ref
>
>
> I'm inclined to use the return-value method, but what do y'all think?
>
I vote yes for return-value method.
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
