MVC in Python
Mike C. Fletcher
mcfletch at rogers.com
Tue Aug 5 01:02:08 EDT 2003
Troy Melhase wrote:
>MK wrote:
>
>
>>How to achieve this feat in Python? Which techniques
>>do you guys use?
>>
>>
>
>Hi MK:
>
>If memory serves (and it rarely does), you have two options. The first
>would be custom wx events, and the second would be the evtmgr module in the
>wxPython.lib package. Both approaches have examples in the wx demo
>application. The evtmgr demo is absolutely dazzling in its simplicity, and
>I would suggest you start your search there.
>
>
Another option: a number of people also use the
multi-consumer-multi-producer "dispatcher" engine. There's a sourceforge
project for the latest version here:
http://sourceforge.net/projects/pydispatcher/
I've used it in both OpenGLContext and ConflictSolver/wxPython
Properties Distribution (and helped a little with putting together the
above project).
* It's *not* GUI-lib specific, but it works nicely with GUI
libraries (and was, IIRC originally created for use with a GUI
library), so your model objects don't have dependencies on the GUI
code at all, but can readily generate events to which the GUI can
subscribe.
* There's no requirement that your objects be aware of the
event-routing infrastructure.
* Registering interest doesn't (generally) affect object lifetimes
(that is, dispatcher uses weak references by default (and has
special code to allow safe weak references to methods of objects),
so that when objects go away their associated routing tables are
also cleaned up).
The basic pattern is to register interest in certain classes of messages
(which are just any hashable value, and may be a special "Any" message
to recieve all messages) from a specific sender, any sender, or a
special "anonymous" sender. That interest is registered by passing in a
callable object (a "receiver"). You then send messages, specifying the
sender (which can be "Anonymous") and the message. The system finds all
receivers which have registered interest that matches the sender +
message combination, figures out what part of the arguments to the
message are applicable to the particular receiver, and collects the
results of delivering the message to each receiver.
All-in-all, it's a good system for normal application event routing, but
to be clear, it's not:
* an IPC mechanism... this is an in-process mechanism (though IIRC
someone has done some experimenting with doing RPC calls with it)
* asynchronous (message delivery occurs at the moment you call "send")
* protected against event looping (you have to do that in your own
code), i.e. it won't detect that method q is sending an event to
itself
* guaranteed (this isn't an enterprise application routing
infrastructure with guaranteed message delivery, input and output
queues, logging and the like, it's a lightweight framework for
desktop application development)
* highly scalable (you don't want to load 100s of thousands of
highly dynamic (i.e. disappearing and reappearing rapidly, and/or
constantly changing their routing parameters) nodes, (though the
version above does include significant improvements beyond the
original Python Cookbook version in this regard)).
That said, it's right up the MVC for desktop applications alley, so I'd
suggest taking a look.
Enjoy yourself,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
More information about the Python-list
mailing list