Using MVC when the model is dynamic

[Mitch Chapman]

Brian Kelley wrote:
> Cameron Laird wrote:
> 
>>> 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.
>>>
>> Was an interest for fast communications from user to model
>> desired? Or was the question solely along the lines of, is
>> there an architecture that'll permit the View to keep up
>> with the Model more-or-less in real time?
> 
> 
> You are correct in what the original poster wanted (i.e. is
> there an architecture that'll permit the View to keep up
> with the Model more-or-less in real time).  I was just being pedantic :)

Hi Brian :)

I'm confused by the comments about the model needing to poll for new
instructions from the view.  (BTW does this mean you usually prefer to
combine view and controller responsibilities in a single entity, rather
than implement them separately?)

Why not just have the model provide control methods which clients can
invoke directly (t. ex. the stop() method in the example I posted)?
Are you saying this doesn't fit well in wxPython, that it's more
natural in that environment to communicate via event codes and queues?

If that's the case, can you define a model-controller class which
receives view events and translates them into method invocations on
an associated model?  That does seem like a lot of work, but it
would let the model remain ignorant of -- loosely coupled to --
its observers.

--
Mitch