> > 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]