something that was introduced in 2/2.1 of CGI::Application was the ability to put a call-back in place of the cgiapp->mode_param( &callback_here ) so that you could programmatically determine run-mode. I agree with Elizabeth that IF you want to add another decision maker to CGI::App, it would have to be programmatic, or at least have the same duality of the current mode_param implementation.
-Stephen -----Original Message----- From: Elizabeth Vaughn [mailto:[EMAIL PROTECTED]] Sent: Friday, December 21, 2001 07:51 AM To: 'Mark Stosberg'; 'Tim Colson' Cc: [EMAIL PROTECTED] Subject: RE: [cgiapp] Grab output of a run mode without headers -- possible solution? Part 2 > -----Original Message----- > From: Mark Stosberg [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 20, 2001 5:50 PM > To: Tim Colson > Cc: [EMAIL PROTECTED] > Subject: RE: [cgiapp] Grab output of a run mode without headers -- > possible solution? Part 2 > > > On Thu, 20 Dec 2001, Tim Colson wrote: > > > > I agree. What about adding another run mode to CGI::App > to handle this. > > > return $self->return_rm($FORM{return_rm}, > @args_to_pass_to_run_mode); > > > That would just be some syntactic sugar to rewrite the > eval statement. > > True. I'd prefer though to have the sugar placed into the framework. > > > > As Elizabeth has pointed out, you've got a decision tree > (albeit small) > > inside each of your run_mode/actions. > > > > "failed" - If validation fails -> send the form > > "success" - If validation ok, and save ok -> send the next page > > Agreed. > > > Why not just return those states and let the App figure out > what to do? :-) > > I think it's a question of organization and scale. Since I'm confident > that I will always make the same decisions upon success and failure of > validation, I prefer to have that logic right there in the code rather > than somewhere else, because it's more direct to read and debug. > > However, in another case if I had the same logic throughout my > application _and_ I thought it might change, it would make > sense to have > this "sub run-mode decision tree" abstracted. That use-case > just hasn't > come for me yet, though. :) > > Hi Tim and Mark, What if the decision is based on something other than success/failure. Examples might be: 1) the type of user that is logged in (where the different types are evolving), or 2) a value that is retrieved from a database where the number of choices grows with the application and the value can be modified from more than one place. You get the general idea - success/failure may be relatively easy to predict and pretty stable over the long haul. It's when the decision is resting on something more fluid that this really gets interesting. Elizabeth --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
