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 ----- Original Message ----- From: "Jesse Erlbaum" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 06, 2002 3:03 PM Subject: [cgiapp] cgiapp_prerun() method > Hey Cory -- > > > My Hero. This new method is great! > > Hehe... I'm glad you like it. > > > 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. > > 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): > > > sub cgiapp_prerun { > my $self = shift; > my $run_mode = shift; > > unless ($self->is_user_allowed($run_mode)) { > return "show_login_form"; > } > > return $run_mode; > } > > > 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!) > > 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 { > my $self = shift; > my $run_mode = shift; > > unless ($self->is_user_allowed($run_mode)) { > $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. > > > 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. > > > 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? > > > TTYL, > > -Jesse- > > > > Jesse Erlbaum, CTO > Vanguard Media > http://www.vm.com > 212.242.5317 x115 > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
