Hey Jesse -
(I've been out for a week..catching up now.)
> > > > rm(SaveData)->rm(ProductMenu)->output(ProductMenu w/
> > standard leftnav)
> The run-mode is what should make the decision as to what the user
> sees next.
I agree. But I think we still are missing each other's points on how that
happens.
> This is why I suggestively called my example run-mode
> "update_record_and_return_to_menu".
> I hoped to create an example run-mode,
> the behavior of which was rather unambiguous.
Yes, that is indeed clear. But not the situation I want to have, as I do not
want my forms to dictate what's next. I want the run-mode to figure that out
from a pre-defined config that says "Successful " SaveData actions go "HERE"
and "Failed" SaveData actions go "THERE".
> In my example, you have one
> run-mode which saves data and then sends the user to a menu. Another
> run-mode might save the data and send the user to a second HTML form
> ('update_record_and_continue').
Heh heh... okay, so now I get to ask where that decision was pushed to in
your app?
That is, if there are multiple run-modes like :
1) update_record_and_continue
2) update_record_and_return_to_menu
3) update_record_and_return_error_mesg
First off, in this paradigm the PREVIOUS run-mode had to tell the Form where
to go next. Secondly this decision is inflexible if not a bit clairvoyant.
;-)
Ex. How could the previous runmode possibly predict that I was going to type
in something bad and return the error_mesg ? <grin>
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
