Hi Tim!
> Heh heh... okay, so now I get to ask where that decision was
> pushed to in
> your app?
Always an important question!
> 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.
The previous run-mode doesn't really have to have any knowledge of the next
run-mode. What you do have to have is a specification which maps out these
decisions before you actually write code. Sometimes the presence of a
specification makes me appear to be clairvoyant to my clients, but I am not
aware of any requirement for supernatural powers. :-)
I find that once you specify what you actually want to do, the
implementation usually designs itself. Because of that, my focus is always
on specification first and implementation details second, which is why I
prefer to talk in concrete use-cases -- not abstractions.
In lieu of a specific example, I can tell you that 99% of my run-modes
statically define what comes next, and I have not felt limited by design in
the functionality I can implement.
In the 1% of the other cases we might have a particular screen which, when
"submitted", needs to go to a different place depending on the situation.
The only example I can think of is a login screen which, when login is
complete, needs to send the user to their originally intended destination.
In this specific case, the login screen is passed a form parameter
("target_uri") which is the location to which the user should be redirected
when login is complete. The process looks sort of like this:
1. Authorization system detects that user requires login to retrieve the
URI they requested.
2. Authorization pushes URI of restricted document into $target_uri. User
is redirected to login application, with $target_uri passed via form data.
3. Login program displays form. (e.g.: "User ID", "Password" fields)
4. User submits data. If invalid, user is returned to login form w/ error
message.
5. If successful, user is logged in. An HTTP redirect is issued to send
the user to $target_uri.
Like I said, this is an a-typical case. 99% of the time, connections are
statically defined. "Screen A" always sends the user to "Screen B" when the
former is successfully submitted.
One note: "Screen A" may have multiple buttons on it which may take the
user to "Screen B", "Screen C" and "Screen D". The buttons on "Screen A"
might invoke a different run-mode in each case. The run-modes might be
"do_and_go_B", "do_and_go_C" and "do_and_go_D", respectively. If "Screen A"
was a "save user" screen, each of the three possible run-modes would
probably call the save_user() Model method as part of their "do"
responsibility. This eliminates redundancy and provides encapsulation.
> Ex. How could the previous runmode possibly predict that I
> was going to type
> in something bad and return the error_mesg ? <grin>
Exception handling is a special case. You have to choose how you want to
handle all the possible error cases. For instance:
* Can't connect to database: Fatal -- 500 error
* Missing field: Return to form with error message
* Requires login: Send to login form
...Etc. In these cases, the exception handling is still static. I have
yet to come across a case where "Screen A" would have to dynamically choose
an error screen for "Error 1". "Screen A", "Error 1" will always show
"Screen A, Error 1 message". Find me a specific use-case where this is not
the case. I am all ears!
Please remember, however: I differentiate "Model" functions from
"Controller" run-modes. I might have a function "save_new_user()" which is
called by my "user registration" application or a cron-based process. If
save_new_user() fails at the function level, those different applications
will respond differently. That's a whole different thing, and it is not
incompatible with the design I have described.
TTYL,
-Jesse-
----
Jesse Erlbaum, CTO
Vanguard Media
212.242.5317 x115
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
