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, 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

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]
                # 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.
        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

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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to