Re: [Zope-dev] ZPatterns framework improvements
Phillip J. Eby:
> >> I'm not actually real fond of the DDO term, because "Dynamic Data Object"
> >> doesn't quite do justice to what these things actually are. I am
> >> definitely open to suggestions for a better name. (Facade? PlaceHolder?
> >> InsideOutObject? ExternalDataObject? BrainInjectedObject?)
> >
> >ZopeTupperware, AloofAttributeObjects, DataSkins :)
> >
>
> I think I'm going to go with DataSkins. Thanks for the suggestion. :)
>
Hey, I did something for you for a change. ;)
> Now I need a name for another interesting ZPatterns 0.4.0 object...
>
> I was working on "indexing" plugins for DataManagers (Racks, Specialists,
> and DataInjectors) and at one point I realized that you could use them for
> things besides indexing.
>
Oh no, the extendability bug has bit him on the ...
> The basic idea is that an "indexing" plugin receives objectAdded(),
> objectChanging(), objectChanged(), and objectDeleted() messages from its
> DataManager. The idea was that it would then be able to update an index
> (such as a ZCatalog) accordingly. But during one of the PTK discussions
> about member registration, it occurred to me that a "registration index"
> could note the addition of a user, and then e-mail them or do other
> operations specific to that portal's business rules. That seemed like an
> interesting hack of indexes, but then after a while I realized that these
> plugins could enforce any other business rules related to changes of
> objects or their addition/deletion. They could, for example, be reverse
> indexes that, whenever a new information item was added, they looked up
> saved search preferences to find who was looking for the new item. They
> could notify a manager about an expenditure greater than a certain amount.
> They could roll back transactions if certain conditions weren't met. And
> it all could be done outside the object itself, in the sense that these
> things would be extensions to the object's class, based on its location in
> the Zope filesystem.
>
> So anyway, "index" now seems rather inadequate to describe these indexing,
> search-agenting, business-ruling objects. (Change Monitors? Knowbots?
> Indexing Agents? Index Rules? Object Matchers?) If you have any name
> suggestions, I'd love to hear 'em. :) I think it would be good if the
> name implied both major capabilities, although I think I might just end up
> having two seperate tabs ("Indexes" and "Rules") just to make the
> capabilities clearer. It's just that DataManager derivatives already have
> so darn many tabs (Methods, Attribute Providers, Sheet Providers, etc.).
>
Hmmm. Behaviorators, DoAsISayDammit, DispatchAgents, ConventionBots,
Facilitators
Jason Spisak
CIO
HireTechs.com
6151 West Century Boulevard
Suite 900
Los Angeles, CA 90045
P. 310.665.3444
F. 310.665.3544
Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission. Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
At 12:14 PM 5/22/00 -0400, Tres Seaver wrote: >"Phillip J. Eby" wrote: >> >> At 03:51 PM 5/21/00 -0400, Tres Seaver wrote: >> > >> >This is really just the classic Observer pattern, a la GoF Design >> >Patterns. "ObjectAdded" and "ObjectRemoved" are events a >> >"RackObserver" would register for; "AfterCreate", "Changed", >> >and "BeforeDestroy" are events of the "hosted" object itself. Note >> >that "ObjectAdded" and "ObjectRemoved" would be called during move or >> >rename operations, even though the object is not being created. >> >> Yes, but the DataManager will filter that such that Zope "Move" and >> "Rename" operations will show to Indexing and Rule agents as though >> they were just "Change" events. See the DataManagementEvents entry >> in the new ZPatterns Wiki for details on how this will work. > >This design has the unfortunate side effect of coupling an object >tightly >to a single location. Properly speaking, objects shouldn't "know" about >their containers; the container should be responsible for handling any >operations which depend on it. Consider a Unix file system: the >command >to get rid of a file is "rm," which is an operation on the *directory*, >not >on the file/subdirectory; it only causes the file to be deleted if the >current directory was the only one with a link to the file. >CatalogAware >is currently broken (as Evan just pointed out to me) because it tries >too >hard to know about its container's path; it would be better if the >container were responsible for doing the >index_object/reindex_object/unindex_object stuff, and not the object >itself. > You've lost me here. DataManager doesn't care about the object's path. The filtering I was referring to is that the DataManager recognizes a delete followed by an add of the same object (as determined by python "id()" value) as a change operation. It only does this if the add occurs under the domain of the same DataManager, otherwise one DataManager will see a delete and the other will see an add. If you move an object between two locations served by the same data manager, then the move or rename is effectively only a change of the object's path, and any Providers/Agents that care about the path would want to know that it changed. Either way, the notifications follow the reality of the situation. For event management purposes, DataManager does *not* identify objects by anything other than their Python pointer value, and that only for the duration of a (sub)transaction. It is up to the specific Providers and Agents to use whatever identification scheme they want, since different attributes of an object might be used as a key for different external databases. For example, in an X10 home automation project, you might have an IndexingAgent that identified a controller by its Zope path, but the RuleAgent that actually turned lights on and off would want to identify the controllers by their X10 house/unit codes. Hm.. one thing all this makes me realize, though... Providers and Agents will also have to do some "same-object add/delete" recognition, because if the same provider or agent is shared by two DataManagers and the object moves from the scope of one to the scope of the other, it's not *really* an add/delete from *that* agent's perspective, even if it is in general to the DataManager. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
"Phillip J. Eby" wrote: > > At 03:51 PM 5/21/00 -0400, Tres Seaver wrote: > > > >This is really just the classic Observer pattern, a la GoF Design > >Patterns. "ObjectAdded" and "ObjectRemoved" are events a > >"RackObserver" would register for; "AfterCreate", "Changed", > >and "BeforeDestroy" are events of the "hosted" object itself. Note > >that "ObjectAdded" and "ObjectRemoved" would be called during move or > >rename operations, even though the object is not being created. > > Yes, but the DataManager will filter that such that Zope "Move" and > "Rename" operations will show to Indexing and Rule agents as though > they were just "Change" events. See the DataManagementEvents entry > in the new ZPatterns Wiki for details on how this will work. This design has the unfortunate side effect of coupling an object tightly to a single location. Properly speaking, objects shouldn't "know" about their containers; the container should be responsible for handling any operations which depend on it. Consider a Unix file system: the command to get rid of a file is "rm," which is an operation on the *directory*, not on the file/subdirectory; it only causes the file to be deleted if the current directory was the only one with a link to the file. CatalogAware is currently broken (as Evan just pointed out to me) because it tries too hard to know about its container's path; it would be better if the container were responsible for doing the index_object/reindex_object/unindex_object stuff, and not the object itself. Tres. -- === Tres Seaver Digital Creations[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Re: [Zope-dev] ZPatterns framework improvements
At 03:51 PM 5/21/00 -0400, Tres Seaver wrote: > >This is really just the classic Observer pattern, a la GoF Design >Patterns. "ObjectAdded" and "ObjectRemoved" are events a >"RackObserver" would register for; "AfterCreate", "Changed", >and "BeforeDestroy" are events of the "hosted" object itself. Note >that "ObjectAdded" and "ObjectRemoved" would be called during move or >rename operations, even though the object is not being created. Yes, but the DataManager will filter that such that Zope "Move" and "Rename" operations will show to Indexing and Rule agents as though they were just "Change" events. See the DataManagementEvents entry in the new ZPatterns Wiki for details on how this will work. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Re: [Zope-dev] ZPatterns framework improvements
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>
> At 05:28 PM 5/19/00 +, Jason Spisak wrote:
> >Phillip J. Eby:
> >
> >> I'm not actually real fond of the DDO term, because "Dynamic
> >> Data Object"
> >> doesn't quite do justice to what these things actually are. I am
> >> definitely open to suggestions for a better name. (Facade?
> >> PlaceHolder?
> >> InsideOutObject? ExternalDataObject? BrainInjectedObject?)
> >
> >ZopeTupperware, AloofAttributeObjects, DataSkins :)
> >
>
> I think I'm going to go with DataSkins. Thanks for the suggestion. :)
>
> Now I need a name for another interesting ZPatterns 0.4.0 object...
>
> I was working on "indexing" plugins for DataManagers (Racks,
> Specialists, and DataInjectors) and at one point I realized that
> you could use them for things besides indexing.
>
> The basic idea is that an "indexing" plugin receives objectAdded(),
> objectChanging(), objectChanged(), and objectDeleted() messages
> from its DataManager. The idea was that it would then be able to
> update an index (such as a ZCatalog) accordingly. But during one
> of the PTK discussions about member registration, it occurred to
> me that a "registration index" could note the addition of a user,
> and then e-mail them or do other operations specific to that
> portal's business rules. That seemed like an interesting hack of
> indexes, but then after a while I realized that these
> plugins could enforce any other business rules related to changes
> of objects or their addition/deletion. They could, for example, be
> reverse indexes that, whenever a new information item was added,
> they looked up saved search preferences to find who was looking for
> the new item. They could notify a manager about an expenditure
> greater than a certain amount. They could roll back transactions if
> certain conditions weren't met. And it all could be done outside the
> object itself, in the sense that these things would be extensions to
> the object's class, based on its location in the Zope filesystem.
>
> So anyway, "index" now seems rather inadequate to describe these
> indexing, search-agenting, business-ruling objects.
> (Change Monitors? Knowbots? Indexing Agents? Index Rules? Object
> Matchers?) If you have any name suggestions, I'd love to hear
> 'em. :) I think it would be good if the name implied both major
> capabilities, although I think I might just end up having two
> seperate tabs ("Indexes" and "Rules") just to make the capabilities
> clearer. It's just that DataManager derivatives already have
> so darn many tabs (Methods, Attribute Providers, Sheet Providers,
> etc.).
This is really just the classic Observer pattern, a la GoF Design
Patterns. "ObjectAdded" and "ObjectRemoved" are events a
"RackObserver" would register for; "AfterCreate", "Changed",
and "BeforeDestroy" are events of the "hosted" object itself. Note
that "ObjectAdded" and "ObjectRemoved" would be called during move or
rename operations, even though the object is not being created.
Tres.
--
=
Tres Seaver [EMAIL PROTECTED]
Digital Creations "Zope Dealers" http://www.zope.org
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
"Phillip J. Eby" wrote: > > So anyway, "index" now seems rather inadequate to describe these indexing, > search-agenting, business-ruling objects. (Change Monitors? Knowbots? > Indexing Agents? Index Rules? Object Matchers?) If you have any name > suggestions, I'd love to hear 'em. :) - PushMePullYu ;-) - MetaManager - Trigger (TriggerManager) - IndexManager - RuleManager HTH, Michael Bernstein ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
- Original Message - From: "Phillip J. Eby" <[EMAIL PROTECTED]> To: "Jason Spisak" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, May 21, 2000 11:14 AM Subject: Re: [Zope-dev] ZPatterns framework improvements > The basic idea is that an "indexing" plugin receives objectAdded(), > objectChanging(), objectChanged(), and objectDeleted() messages from its > DataManager. The idea was that it would then be able to update an index > (such as a ZCatalog) accordingly. But during one of the PTK discussions > about member registration, it occurred to me that a "registration index" > could note the addition of a user, and then e-mail them or do other > operations specific to that portal's business rules. [other great examples of this capability snipped] You could call these "ChangeBrains". It's got a bit of alliteration to it :) After reading Steve Alexander's message this morning, I started thinking about how the Portal capabilities could be refactored into one or more Specialists. This feature is also a very neat way for people to set up their review policies for the Portal. I'll send a message with more detail about my thoughts on a Portal Specialist over on the zope-ptk list. I just wanted to chime in and say that I agree that ChangeBrains (or whatever) are a Really Useful Thing. Kevin ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
At 05:28 PM 5/19/00 +, Jason Spisak wrote:
>Phillip J. Eby:
>
>> I'm not actually real fond of the DDO term, because "Dynamic Data Object"
>> doesn't quite do justice to what these things actually are. I am
>> definitely open to suggestions for a better name. (Facade? PlaceHolder?
>> InsideOutObject? ExternalDataObject? BrainInjectedObject?)
>
>ZopeTupperware, AloofAttributeObjects, DataSkins :)
>
I think I'm going to go with DataSkins. Thanks for the suggestion. :)
Now I need a name for another interesting ZPatterns 0.4.0 object...
I was working on "indexing" plugins for DataManagers (Racks, Specialists,
and DataInjectors) and at one point I realized that you could use them for
things besides indexing.
The basic idea is that an "indexing" plugin receives objectAdded(),
objectChanging(), objectChanged(), and objectDeleted() messages from its
DataManager. The idea was that it would then be able to update an index
(such as a ZCatalog) accordingly. But during one of the PTK discussions
about member registration, it occurred to me that a "registration index"
could note the addition of a user, and then e-mail them or do other
operations specific to that portal's business rules. That seemed like an
interesting hack of indexes, but then after a while I realized that these
plugins could enforce any other business rules related to changes of
objects or their addition/deletion. They could, for example, be reverse
indexes that, whenever a new information item was added, they looked up
saved search preferences to find who was looking for the new item. They
could notify a manager about an expenditure greater than a certain amount.
They could roll back transactions if certain conditions weren't met. And
it all could be done outside the object itself, in the sense that these
things would be extensions to the object's class, based on its location in
the Zope filesystem.
So anyway, "index" now seems rather inadequate to describe these indexing,
search-agenting, business-ruling objects. (Change Monitors? Knowbots?
Indexing Agents? Index Rules? Object Matchers?) If you have any name
suggestions, I'd love to hear 'em. :) I think it would be good if the
name implied both major capabilities, although I think I might just end up
having two seperate tabs ("Indexes" and "Rules") just to make the
capabilities clearer. It's just that DataManager derivatives already have
so darn many tabs (Methods, Attribute Providers, Sheet Providers, etc.).
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
Phillip J. Eby:
> In ZPatterns 0.4.0 and beyond, RackMountables will probably change their
> name to DynamicDataObjects, or DDO's for short. This is to reflect their
> new, wider scope, which does not require them to be mounted in a Rack to
> have their dynamic features. They will be able to have providers manage
> their data no matter where they are in a Zope application, so long as the
> DDO is in acquisition context of a ZDMFolder ("Folder w/Data Management
> Support") that has a ZDataManager plug-in registered for the DDO's meta_type.
This sounds amazingly flexible.
>
> I'm not actually real fond of the DDO term, because "Dynamic Data Object"
> doesn't quite do justice to what these things actually are. I am
> definitely open to suggestions for a better name. (Facade? PlaceHolder?
> InsideOutObject? ExternalDataObject? BrainInjectedObject?)
ZopeTupperware, AloofAttributeObjects, DataSkins :)
>
> Also, while I'm babbling about versions, it's important to note at this
> point that ZPatterns versions below 1.0.0 should be considered subject to
> change even with respect to developer-level API's. They get more stable as
> the number gets higher, which is why LoginManager changed a lot less
> between 0.8.0 and 0.8.5 than half as much as ZPatterns changed between
> 0.2.0 and 0.3.0. The change to 0.4.0 will probably be another big jump,
> due to the DDO stuff as well as the Indexes stuff. Predicates may even
> make it in, in some small way.
This is one of the reasons I am just looking a tinkering. But this is
definately is the future of instance data and data presentation in Zope.
All my best,
Jason Spisak
CIO
HireTechs.com
6151 West Century Boulevard
Suite 900
Los Angeles, CA 90045
P. 310.665.3444
F. 310.665.3544
Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission. Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
"Phillip J. Eby" a écrit : > Good point, but ordinarily one mixes RackMountable with another Zope class > such as SimpleItem.Item, or uses it as part of a ZClass. In either case, > Acquisition gets added in. SimpleItem.Item only subclasses ExtensionClass.Base, and I got an AttributeError on __of__ unless my RackMountable subclasses Acquisition.Implicit also. bizarre isn't it? > I'm not actually real fond of the DDO term, because "Dynamic Data Object" > doesn't quite do justice to what these things actually are. I am > definitely open to suggestions for a better name. (Facade? PlaceHolder? > InsideOutObject? ExternalDataObject? BrainInjectedObject?) what about "penguin" ? :-) > Also, while I'm babbling about versions, it's important to note at this > point that ZPatterns versions below 1.0.0 should be considered subject to > change even with respect to developer-level API's. They get more stable as > the number gets higher, which is why LoginManager changed a lot less > between 0.8.0 and 0.8.5 than half as much as ZPatterns changed between > 0.2.0 and 0.3.0. The change to 0.4.0 will probably be another big jump, > due to the DDO stuff as well as the Indexes stuff. Predicates may even > make it in, in some small way. Have you got an idea of when 0.4.0 will ship ? regards, jephte clain [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
At 09:46 PM 5/19/00 +0400, Jephte CLAIN wrote:
>Some thought about RackMountables: they should subclass
>Acquisition.Implicit for bobotraversing to work. indeed, the
>__bobo_traverse__ code says:
>
>return getattr(ob, 'aq_base', ob).__of__(self)
>
>ob has the __of__ attribute only if it subclass an extension class
>(Acquisition.Implicit is an easy choice)
Good point, but ordinarily one mixes RackMountable with another Zope class
such as SimpleItem.Item, or uses it as part of a ZClass. In either case,
Acquisition gets added in. I prefer to keep the base class as free as
possible of things that will be mixed in later to avoid repeated
inheritance. Also, for what it's worth, future versions of RackMountable
will define their own __of__ method, as it will be required to support
placement of rackmountable-ish objects in places other than racks.
>in AttributeProviders.py, around line 199, definition of
>_DelAttributeFor is bogus. Instead of:
Noted and fixed for next release.
>It is desirable for me to enumerate the objects stored in the racks for
>a specialist. Because the __readableStorage is not accessible from
>derived classes (magic of ExtensionClasses ???), I can't add that
>behavior without patching Rack.py
>
>I'm thinking of a method 'rsValues' that enumerate values in the
>readableStorage. In Rack.Rack:
>
>def rsValues(self):
> """rsValues like 'readableStorageValues'
> why on earth are there __readableStorage and __writableStorage ???
> """
__readableStorage and __writeableStorage are designed to prevent
side-effect transactions occurring. It's a little bit tricky, but
basically __readableStorage doesn't create a storage if it hasn't already
been created - it instead returns an empty dictionary. __writeableStorage
creates the storage if it doesn't exist. Thus, operations that only intend
to read data from the storage don't cause a write transaction when the
storage doesn't yet exist.
> values = []
> slots = self.__readableStorage.values()
> for slot in slots:
> # the following took from retrieveItem
> item = slot[SelfKey]
> item._setSlot(slot)
> item._clearPerTransactionCache()
> # associate the rack to the item
> item._setRack(getattr(self, 'aq_inner', self))
> ## the above line could be written
> # item._setRack(self.aq_inner)
> ## if racks objects where always wrapped.
> values.append(item)
> return values
>
>Or is it best to create a catalog in the specialist that index all
>objects stored in the rack as they get added?
Yes, that is the best route for the current version. Future versions will
support an "Indexes" tab for plugins that manage search and retrieval.
This tab will be on both Specialists and Racks, as well as on the new
ZDataManager class that allows Providers and Indexes on objects stored in
Folders or other "normal" ZODB locations.
>The default ZODB storage should give the ability to enumerate the
>objects, even if it does not belong to the standard "interface" of the
>rack.
Something like that will be included, but it will be in the form of a
plugin that goes on the Indexes tab, which the Rack can call. At that
point, searching/enumerating *will* be part of the Rack interface.
>I understand now that the RackMountable is only a placeholder class, and
>that attributes and sheets are managed by AttributeProviders and
>SheetProviders, right?
That is correct. RackMountables are like abstract classes that only have
domain knowledge (application-level intentions) with no data storage
implementation knowledge.
In ZPatterns 0.4.0 and beyond, RackMountables will probably change their
name to DynamicDataObjects, or DDO's for short. This is to reflect their
new, wider scope, which does not require them to be mounted in a Rack to
have their dynamic features. They will be able to have providers manage
their data no matter where they are in a Zope application, so long as the
DDO is in acquisition context of a ZDMFolder ("Folder w/Data Management
Support") that has a ZDataManager plug-in registered for the DDO's meta_type.
I'm not actually real fond of the DDO term, because "Dynamic Data Object"
doesn't quite do justice to what these things actually are. I am
definitely open to suggestions for a better name. (Facade? PlaceHolder?
InsideOutObject? ExternalDataObject? BrainInjectedObject?)
Also, while I'm babbling about versions, it's important to note at this
point that ZPatterns versions below 1.0.0 should be considered subject to
change even with respect to developer-level API's. They get more stable as
the number gets higher, which is why LoginManager changed a lot less
between 0.8.0 and 0.8.5 than half as much as ZPatterns changed between
0.2.0 and 0.3.0. The change to 0.4.0 will probably be another big jump,
due to the DDO stuff as well as the Indexes stuff
[Zope-dev] ZPatterns framework improvements
sorry, I can't reproduce the error I talked about yesterday. All the insights given by philip has lighted up my path :-) There are four points I want to discuss: *** Some thought about RackMountables: they should subclass Acquisition.Implicit for bobotraversing to work. indeed, the __bobo_traverse__ code says: return getattr(ob, 'aq_base', ob).__of__(self) ob has the __of__ attribute only if it subclass an extension class (Acquisition.Implicit is an easy choice) *** in AttributeProviders.py, around line 199, definition of _DelAttributeFor is bogus. Instead of: def _DelAttributeFor(self,client,name): return self.aq_parent.aq_parent._SetAttributeFor(client,name) it should read: def _DelAttributeFor(self,client,name): return self.aq_parent.aq_parent._DelAttributeFor(client,name) *** It is desirable for me to enumerate the objects stored in the racks for a specialist. Because the __readableStorage is not accessible from derived classes (magic of ExtensionClasses ???), I can't add that behavior without patching Rack.py I'm thinking of a method 'rsValues' that enumerate values in the readableStorage. In Rack.Rack: def rsValues(self): """rsValues like 'readableStorageValues' why on earth are there __readableStorage and __writableStorage ??? """ values = [] slots = self.__readableStorage.values() for slot in slots: # the following took from retrieveItem item = slot[SelfKey] item._setSlot(slot) item._clearPerTransactionCache() # associate the rack to the item item._setRack(getattr(self, 'aq_inner', self)) ## the above line could be written # item._setRack(self.aq_inner) ## if racks objects where always wrapped. values.append(item) return values Or is it best to create a catalog in the specialist that index all objects stored in the rack as they get added? The default ZODB storage should give the ability to enumerate the objects, even if it does not belong to the standard "interface" of the rack. *** I understand now that the RackMountable is only a placeholder class, and that attributes and sheets are managed by AttributeProviders and SheetProviders, right? any comments? jephte clain [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
