trinket : model view controller pattern

basics
interests
projects
evolving coordination model-view-controller genetic algorithms ... as virtual user managers resource allocation networked snake cellular automata
vitae
story
kids iPhone apps
s100+ pages

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 stopHeart method in the model. The "bore" and "excite" buttons both call the adjustExcitementLevel in the model. The difference is that "bore" will trigger a call with a positive amount (to increase the delay) and "excite" will trigger a call with a negative amount (to decrease the delay).

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 HeartBeat class), which calls the update method within the applet. The applet's thread ends when the user leaves the page, but the HeartBeat isn't stopped. So, this applet's stop method (which is invoked when the user leaves the page the applet is on) acts as a very simple controller, calling the model's stopHeart method to stop the HeartBeat. Notice how we've been able to adapt the various model methods in order to create a more friendly user interface.

Implementation note

Some 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...