> 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
Why not just return those states and let the App figure out what to do? :-)
That way if you have 20 actions, and change your mind later about what
happens upon a "failure"... you don't have to touch all 20 actions... just
the new mapping of "failure" to "flogging" which then ends in "send form".
;-)
> which is one of things I like about CGI::App -- simple interface.
I agree. Simpler is better.
But the flipside of that coin is that if you've got those eval's in all your
run-modes/actions... doesn't it make sense to move that task up into the
parent fw and do it consistently in one place instead of copy/paste to a lot
of actions?
Again, as Elizabeth has noted, this could be done so that folks could
continue the "run-mode->output" paradigm...or freaks like me could take
advantage of a "run-mode->run-mode->?->output" situation. <grin>
Oh, and one final thought...with your eval and/or the
$self->return_rm()...this binds one run_mode tightly to another run_mode.
Seems to me, that each run_mode shouldn't really know anything about other
run_modes. Breaks encapselation rules, doesn't it? Seems to me, it would
make it harder to change and/or remove run_mode_foo if other run_modes could
be calling directly to run_mode_foo(@arglist).
The pseudo code I was talking about should de-couple the run_modes from each
other... since they won't know specifically what happens next. But then, I
could be talking complete bullocks. ;-)
> So I'm torn. I think if it was in there, I'd use it. :)
:-)
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
