Using MVC when the model is dynamic

[Brian Kelley]

Mitch Chapman wrote:

> Model -- runs a simple computation in a background thread.  The
> Model's state is an Observable.
> 
> View -- displays a model's state as shown above.  Also processes
> keyboard input, looking for a line starting with 'Q' or 'q' as
> a shutdown request.
> 
> App -- acts like a controller, but also includes the application's
> main event loop, which blocks until keyboard input is available.
> 
> 
> The Model and View know nothing about each other.  The
> App glues them together; it tells the View to update whenever
> the Model state changes.  It also routes user input (keyboard
> input, in this case) to the View.  This is a common way
> to build MVC applications, and it addresses your concern about
> controls which are designed only for user-driven changes.

Hi Mitch :)  Note that Mitch's example won't work on windows since you 
can't use select on stdin (only sockets).

I have been playing with two approaches to this issue of dynamically 
changing events from a model.

1) I've recently become a fan of using the GUI's native events to 
control state from the model to the view.  They are thread-safe and easy 
to implement.  wxPython has a good example in their demo of doing this. 
  See the Threads entry of "Process and Events"

Model -> state is an observable ->| generates an event |<- View responds

when the observable is altered a GUI event is posted through the 
callback scheme.  The gui can then asynchronously respond to changes in 
states.  Warning:  sometimes multiple instances of the same event 
handler can be run simultaneously so be careful here.  I usually prevent 
this through some locking mechanism.

This is pretty much the same as Mitch's example except the observable is 
decoupled from the View through the event mechanism.  I expect the same 
could be accomplished using a Queue and a timer.

2) Spawn an independent process and simply monitor the processes 
standard output and respond accordingly.  See the LongRunningTasks entry 
on http://staffa.wi.mit.edu/people/kelley

Both of these gloss over the issue of how does the view talk to the 
model.  The only real answer I have is polling.  The model must 
occasionally poll for new instructions from the view or have it's own 
event-style manager.

Brian Kelley