At 12:45 AM 5/25/00 -0400, Tres Seaver wrote:
Ah, ok -- I was planning simply to leverage the ZODB's facilities for
maintaining persistent references in the DefaultObservable mix-in; more
elaborate schemes would be possible (for instance to support
rack-mounted observers?)
Actually, just using
Michel Pelletier [EMAIL PROTECTED] wrote:
I'll do both, this is absolutely a desperately needed feature in the
ZCatalog. Currently, Cataloged items must take responsibility for
notifying a catalog of their changes instead of the ZCatalog observing
them.
Amos and I talked about this over
Evan Simpson wrote:
This exists! (sort of). ObjectManager.superValues accepts a list of
meta_types, and returns a list of all objects of those meta_types which can
be found in any ObjectManager in the current one's acquisition context.
and has done for ages... the original Squishdot code
Michel Pelletier wrote:
There allready exists such a thing, superValues([meta_type]). But I
think this is too weak to use as a discovery protocol. An observable
may not know or care what type of observer it wants to discover. Also,
when it finds a number of various resources, catalogs lets
At 07:19 PM 5/24/00 -0400, Tres Seaver wrote:
I have started a page for an implementation of the GangOfFour Observer
pattern within Zope:
URL
http://www.zope.org/Members/michel/Projects/Interfaces/ObserverAndNotificat
ion
Please comment, either here or in the wiki.
Is this only for events
"Phillip J. Eby" wrote:
Is this only for events occurring within a transaction, or across
transactions? If across transactions, how do you intend to handle
persistent references, acquisition, and cross-database references?
(My suggestion would be to use a path to the callable.)
Note that
