Hi Tim --
> > > rm(SaveData)->rm(ProductMenu)->output(ProductMenu w/
> standard leftnav)
> > I think what you have here could be constructed in a different way
> > 1. User is on Edit Form. They click "SAVE".
> > 2. The run-mode "update_record_and_return_to_menu" is called:
> That would put bind the decision of what to do next to the
> form itself. As I
> said, "SaveData" doesn't know where it's going next. It might
> produce an
> error page, a product menu, or perhaps this was a two-part
> edit and so it
> needs to go to EditForm #2.
I completely agree! SaveData() should be able to be called in any context,
regardless of what form a user has just submitted, and regardless of what
form is to be displayed next.
By changing SaveData() from a run-mode to a utility function (possibly, but
not necessarily, in a business "Model" class) you completely separate the
function (in this case, saving data for a specific type of object) from the
HTML form (user submits an "edit" form, verses an "add" form, etc.).
> SaveData is likely a very small runmode, but a runmode none the less.
>
> If it wasn't a runmode, where do you send the form to??
>
> Form->runmode(?)
The run-mode is what should make the decision as to what the user sees next.
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. 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').
As long as SaveData() is directly connected to an HTML form, you will have a
problem. If you encapsulate it properly, SaveData() shouldn't care about
the context in which it is called. It can be equally happy being called
from an HTML form, or a cron process!
BTW: For all you Object-Oriented Design enthusiasts, at Vanguard Media we
use UML state-transition diagrams to design CGI::Application modules. We
generally create these diagrams at a level of detail where there is one
"State" per HTML screen. Using this technique, your run-modes are *NOT* the
different state elements. Your run-modes are actually the connections
between each state! This is a subtle point, but a very important one for
understanding the purpose of run-modes as state-transition controllers.
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]
