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