[wxpython-dev] Google SoC Project - MVC

Nitro nitro at dr-code.org
Fri May 30 15:32:03 PDT 2008


Am 30.05.2008, 20:48 Uhr, schrieb Robin Dunn <robin at alldunn.com>:

>> This seems to be a problem, because if I want to subscribe only for the  
>> updates of a specific object it's not (cleanly) possible.
>>  Doing something like
>>  obj = createSomeModelWhichSendsEventsWhenItChanges()
>> Publisher().subscribe( (obj,), obj_all_messages_handler )
>> Publisher().subscribe( (obj, 'sizeChanged'), obj_size_changed_handler )
>>  is not possible right now.
>
> If obj has a unique name then you can just use that for a component of  
> the topic name.

Yes. But this means I have to generate a unique name for every object  
that's ever part of the MVC mechanism. This could be realized by using a  
factory function or by inheriting the objects in question from some base  
class which provides the capabilities.

>
>> Maybe you could set the topic to (str(id(obj)),), but that doesn't seem  
>> like a clean solution.
>
> It amounts to almost the same thing, except with a name then the  
> programmer could set that if they want to be able to use it later for  
> some reason, like a find object by name function.

The programmer might use non-unique names, maybe even between unrelated  
objects and this might cause problems. So I think one needs to distinguish  
between a unique ID of an object and its name.
Maybe str(hash(obj)) is a better solution, still not the one which I'd  
think is the best though.

>
> Here is another.  Use the hierarchal matching capabilities of pubsub to  
> help with topic filtering and matching.  For example, you might define a  
> rule that all FC topics should use a set number of components, perhaps  
> something like:
>
> 	action.canvasName.layerName.objName
>
> (or the equivalent tuple form.)  Already with pubsub you'll be able to  
> subscribe to messages that are more general or more detailed (from left  
> to right in the topic name.)  For example, you can get all sizeChanged  
> actions in the fooCanvas by just subscribing to "sizeChanged.fooCanvas",  
> or whatever.  Next, add to pubsub the ability to do wildcard topic  
> matches and you'll then be able to go the other direction.  For example  
> to get messages for any action on the redCircle object you can subscribe  
> to "*.*.*.redCircle".  Does that give you everything you need?

The hierarchy is not (yet?) a huge problem. Your ideas surely sound  
convincing when it comes to hierarchy though. I'll remember this. However,  
it does not solve the "topics are only strings or tuples thereof". At  
least you'd have to be able to do something like ('*', '*', '*',  
redCircleObj). Pubsub would then automatically take  
str(hash(redCircleObj)). This could be realized by feeding each topic into  
a canonical_topic() function which just takes the hash() of anything  
that's not a string.
> You may also want to look at pubsub3.  It's the next generation of  
> pubsub forked off into its own project.  I haven't had the time to  
> integrate it back into wxPython but it should probably be done one of  
> these days.

Ahh, I didn't know pubsub was moved out of wxPython. I just read their  
webpage, but it seems topics are still limited to strings. In pubsub3  
you're allowed to only send already registered messages. I implemented  
this for fc, too, but then removed it, because it seemed to be  
counter-productive at times.

-Matthias


More information about the wxpython-dev mailing list