Re: [Zope-dev] Observable Interface?
Chris Withers <chrisw@nipltd.com> asked:
Does anyone know what happened to it and how far its implementation got?
The preliminary implementaion, DefaultObservabale, landed as a mix-in class in Zope 2.2: $ZOPE_HOME/lib/python/OFS/DefaultObservable.py Mix it in to one of your Python base classes (be sure to get it's '__init__()' called!) and fire away. I am currenly working on the more ambitious notion of adding an event channel, which addresses some of the "MxN" problems which plague the classic Observer. See the Zope-PTK archives for August for the latest on that. Tres. -- =============================================================== Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org
Tres Seaver wrote:
Chris Withers <chrisw@nipltd.com> asked:
Does anyone know what happened to it and how far its implementation got?
The preliminary implementaion, DefaultObservabale, landed as a mix-in class in Zope 2.2:
$ZOPE_HOME/lib/python/OFS/DefaultObservable.py
Mix it in to one of your Python base classes (be sure to get it's '__init__()' called!) and fire away.
Where are the docs? Hwo does it work?
I am currenly working on the more ambitious notion of adding an event channel, which addresses some of the "MxN" problems which plague the classic Observer. See the Zope-PTK archives for August for the latest on that.
Looked... any further progress? cheers, Chris
On Fri, 10 Nov 2000, Chris Withers wrote:
Tres Seaver wrote:
Chris Withers <chrisw@nipltd.com> asked:
Does anyone know what happened to it and how far its implementation got?
The preliminary implementaion, DefaultObservabale, landed as a mix-in class in Zope 2.2:
$ZOPE_HOME/lib/python/OFS/DefaultObservable.py
Mix it in to one of your Python base classes (be sure to get it's '__init__()' called!) and fire away.
Where are the docs? Hwo does it work?
The docs are in the interfaces wiki: http://www.zope.org/Members/michel/Interfaces/ObserverAndNotification (Note that this actually predates the fishbowl process -- this has been in Zope for a loooong time).
I am currenly working on the more ambitious notion of adding an event channel, which addresses some of the "MxN" problems which plague the classic Observer. See the Zope-PTK archives for August for the latest on that.
Looked... any further progress?
Nope, the PTK work I have been able to do lately is all stabilization. I am working an a new "PTK Fishbowl" site, where such proposals can be tracked more cleanly. Tres. -- =============================================================== Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org
Tres Seaver wrote:
The docs are in the interfaces wiki:
http://www.zope.org/Members/michel/Interfaces/ObserverAndNotification
(Note that this actually predates the fishbowl process -- this has been in Zope for a loooong time).
Actually at: http://www.zope.org/Members/michel/Projects/Interfaces/ObserverAndNotificati... </pedant> ;-) Does this mean all of the classes in the diagram at that URL have been implemented? How come the Catalog doesn't use it so CatalogAware (bleugh!) isn't needed anymore? Also, is there any documentation about how to actually use the Observable interface? (excuse my ignorance if I've missed it...)
Nope, the PTK work I have been able to do lately is all stabilization. I am working an a new "PTK Fishbowl" site, where such proposals can be tracked more cleanly.
Cool :-) Chris
On Fri, 10 Nov 2000, Chris Withers wrote:
Does this mean all of the classes in the diagram at that URL have been implemented?
How come the Catalog doesn't use it so CatalogAware (bleugh!) isn't needed anymore?
Heh, because we would have to make far-reaching changes (essentially, add an event channel :) to make CA redundant; otherwise, the catalog has no way to know *which* objects to observe (not to mention the problem of maintaining tens of thousands of point-to-point subscriptions within the catalog). Chris Petrilli is working on a fishbowl proposal for CatalogNG; I'm pretty sure he intends to adopt some kind of observer/event scheme to make it work.
Also, is there any documentation about how to actually use the Observable interface? (excuse my ignorance if I've missed it...)
Again, the wiki is it; the code deployed in Zope 2.2 implements the Observable interface, and is intended to be used as a mix-in, like so: from OFS.SimpleItem import SimpleItem from OFS.DefaultObservable import DefaultObservable class Foo( SimpleItem, DefaultObservable ): """ Some foo or other """ ... def bar( self, ... ): """ """ ... self.notify( "bar" ) Clients register with a Foo instance using the methods of the Observable interface, e.g.: foo.registerObserver( self.getPhysicalPath() + ( 'watchFoo',) ) When the Foo instance has its 'bar()' method called, it will notify all registered observers, passing 'bar' as the event; in this case, the client's 'watchFoo()' method will be called, with the foo object and 'bar' passed as parameters. (Thanks for the prodding -- I just checked in a docstring containing the substance of this email.) Tres. -- =============================================================== Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org
Chris Petrilli is working on a fishbowl proposal for CatalogNG; I'm pretty sure he intends to adopt some kind of observer/event scheme to make it work.
CatalogTNG is definately going to be top down, rather than bottom up (its current design). I'm trying to collect a set of requirements currently, which will be used to drive the architecture. I have some ideas on that, but would rather not publicize them until all the requirements are gathered. CatalogTNG is a Zope3 idea. Chris
Christopher Petrilli wrote:
Chris Petrilli is working on a fishbowl proposal for CatalogNG; I'm pretty sure he intends to adopt some kind of observer/event scheme to make it work.
CatalogTNG is definately going to be top down, rather than bottom up (its current design). I'm trying to collect a set of requirements currently, which will be used to drive the architecture. I have some ideas on that, but would rather not publicize them until all the requirements are gathered.
Where are the requirements being gathered? cheers, Chris
Christopher Petrilli wrote:
Chris Petrilli is working on a fishbowl proposal for CatalogNG; I'm pretty sure he intends to adopt some kind of observer/event scheme to make it work.
CatalogTNG is definately going to be top down, rather than bottom up
(its
current design). I'm trying to collect a set of requirements currently, which will be used to drive the architecture. I have some ideas on that, but would rather not publicize them until all the requirements are gathered.
Where are the requirements being gathered?
Right now the requirements are internal before they are released. It'll be tightly tied to the story for Zope3, and therefore will start with core business requirements for DC, then move to public review and modification... Chris
participants (3)
-
Chris Withers -
Christopher Petrilli -
Tres Seaver