Last edited - March / 99
-- Hear and forget; see and remember; do and understand...
the model-view-controller (MVC) design pattern
the heartbeat controller
This controller (source - most of the code was generated
by Symantec's Visual Cafe...the code I added is at the bottom of the file.)
has its own frame where it presents the user with three options: bore,
excite, and stop. The "stop" button will call the
I haven't mentioned one more controller that this
application has. It is a special controller that needed
to be added when the application was put into an applet (source). That is, we want the
model to stop when we leave the page. If it didn't, there
would be a continuous heartbeat sound made as long as the user's browser
was running. This is due to the model having its own
thread (created by the
Implementation noteSome MVC descriptions will suggest linking the view to the controller, but that just adds another level of coupling that hasn't seemed necessary to me (yet?). They suggest that the controller might need to control parts of the view - which I think should just be part of the view. Likewise, if the controller's display relies on the state of the model (in order to display the appropriate buttons or messages), it should be a view in its own right. Sure, the effect can be faked, with the controller maintaining its own variables for the model's supposed state - but this gets messy (bug prone) quickly . Imagine situations where there is more than 1 controller (multi-user, or just multiple ways of affecting the model). Maybe it is because I'm still getting a feel for the MVC pattern, but I prefer keeping the elements pure, where they know as little about each other as possible.
Another trap one might fall into is confusing view controls with model controls. Kyle gave me this example:
A view might be a graph, and the user might want to control how the graph displays a few things (x and y ranges and perhaps scatter plot versus line graph vs bar). Those could be controllers on the view, but I wouldn't put them with any controller of the model. The view params in this case are totally independent of the model, so the controls are safely separated from the model and other controllers and other views.
Now, with that out of the way, we can take a look at how the views work...