On Tue, 16 Jul 2002, Ross Boylan wrote:
> The Zope Developer's Guide and the API docs (Zope 2.5) present
> different stories about how to add things to object managers. I don't
> really follow what the API stuff is doing. This is a request for
> Devguide says do
> def addFunction(dispatcher, id):
> "Create object and add to self"
> p = SomeProduct(id)
> dispatcher.Destination()._setObject(id, p)
> This makes sense, though, as commented at
> it relies on a private, undocumented method. addFunction is in outer
> scope of a module, and is hooked up wtih various calls in ___init__.py.
Call this the "add function". Defined by the product, it is passed
the dispatcher for the ObjectManager to which the object is being added.
As you say, it apparently uses a private function, however despite
it's (historical artifact of a) name, it is the proper way to do
this operation. And it is documented, in the Dev Guide <wry grin>.
> On the other hand, the ObjectManager API says to do
> self.manage_addProduct['OFSP'].manage_addFolder(id, title).
This is the action that non-Product code uses to add an object from
the Product to an arbitrary object manager. 'self' being the object
manager in question (eg: when called from an External Method, self
will be the folder the External Method was called on). This sequence
*calls* the "add function" defined above. In this case, it is
calling the add function defined by the Folder object in the OFSP
> First, what scope should that be done in? Second, this seems to
> create one product (OFSP) and then add a folder to it, so that it
> creates two, nested products.
Actually, it doesn't. This syntax has bothered me since I first
encoutered it, and I'm sure I'm not alone. But we are stuck with
it (for now). "manage_addProduct[<someproductname>]" is, essentially,
a lookup in a registry keyed by product name. So that part looks
up the Product from the registry, and then you have access to the
module level functions in that Product, such as the "add function"
> The API for Folder mentions manage_addFolder as a constructor, but
> again the scope is unclear to me. Presumably it needs to know what to
> add it to, but that is not passed in.
You are calling the method on 'self' in the API example, or on some
other reference to an ObjectManager in some other context.
(Literally 'context' if you were doing this from a pythonscript.)
'manage_addProduct' gets "acquired" (from where I'm not quite sure
<wry grin>), and some magic that I haven't had a need to look in
to arranges things so that your add function gets passed a dispatcher
that has that ObjectManager as its Destination() as its first
argument, followed by whatever arguments (id, title) in the API
example) you pass it explicitly. This is an example of Zope2
"magic" that we are trying hard to eliminate from Zope3 <grin>.
> Finally, the use of id in two places in the first code snippet (one
> apparently associated with the container, the other with the object)
> seems like an invitation to trouble. Why is it done that way?
Tell us about it. This is an old Zope2 (or was it bobo?) design
decision that has been revisited in Zope3. In Zope3, only containers
know about ids in the general case, not the objects referenced by
> One reason I want to know this is that I'm considering having a
> container that would automatically label (or set id) of its contents
> (e.g., 'a' is first, 'b' is second....).
> Thanks for any light you can shed.
Hopefully I haven't told you anything untrue up above, but if I have
someone will doubtless correct me <grin>.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -