[Zope-dev] Object hierarchy in RIPP

[Kevin Dangoor]

Thanks for all of the messages, Phillip. Hopefully, you'll succeed in
getting ZPatterns 0.3.0 out the door tomorrow. Even if you don't, when it
*does* come out there will probably be many more people that are ready to
use it.

----- Original Message -----
From: "Phillip J. Eby" <pje@telecommunity.com>
To: "Kevin Dangoor" <kid@kendermedia.com>; <zope-dev@zope.org>
Sent: Thursday, May 04, 2000 11:31 AM
Subject: Re: [Zope-dev] Object hierarchy in RIPP


> At 10:59 AM 5/4/00 -0400, Kevin Dangoor wrote:
> >    I have a database of products, built from ZClasses. Products are
bundled
> >into groups for convenience of management, and the URL of a product is
based
> >on its SKU. So, we can have a product at products/1/5, and that would be
the
> >item 1-5. This direct traversal to a product object is very useful. The
> >products are all indexed in a ZCatalog, and I do use acquisition to get
at
> >some useful things for displaying these products.
>
> If I were doing what you're doing, I'd use a Products "Specialist" (fka
> Implementor).  Specialists implement bobo_traverse by asking their
enclosed
> Racks for the item.  They also have a methods tab for shared/acquired
stuff.

OK. *Now* I'm a lot clearer on how these things should be used. I didn't
realize that the Specialists implemented bobo_traverse.

I assume that one difference between the Rack and my existing set up is that
if I have a Specialist called "products" and go to
products/manage
I'm not going to see the standard Zope management interface listing out the
products. Correct?

I understand that Racks are meant to solve some of the issues with having
"too many" items in one Folder, in which case you wouldn't *want* the
standard Zope management interface. If/when the API defines search methods,
it might be nice to create a standard "management interface" for Racks that
would let you add instances, search for instances and delete them.

> The only bit I'm not sure about is your mapping of 1-5 to 1/5, which seems
> to me to imply that you have another hierarchy level in there, which Racks
> don't handle per se.  If you have something like a ProductGroup object
> going on in there, then I would have a ProductGroups specialist retrieve
> the ProductGroup, whose bobo_traverse would ask the Products specialist to
> retrieve the product, wrapped with the ProductGroup for acquisition.

You're correct about the "ProductGroup" sort of thing. I will probably
eliminate that, since it sounds like Racks will quite comfortably handle
lots of items.

I see the difference you're getting at, as well. So, I wouldn't try to stuff
a Specialist into another Specialist or onto a Rack. The ProductGroups
Specialist just asks the Products Specialist for a given item. Makes sense.

> That's less than optimal, however.  In a future version of ZPatterns, we
> want to make it possible for RackMountables to live anywhere in the ZODB
> "file system" and still add propertysheets, etc.  Right now, they have to
> live in a Rack because that's where the external data management is.  You
> could hack this pretty easily, however, by making your Folderish objects
> bobo_traverse methods call _setRack on retrieved sub-objects, and pointing
> them to the Rack which is designated for managing their external data.
> That's sort of how we'll be implementing the extension anyway, only we'll
> be doing it in a lot more complicated way involving __of__.  :)

I agree that this flexibility would be nice... But, I don't mind having to
put things in Racks in order to be able to flexibly store information in the
ZODB and RDBMSes.

> By the way, all my comments refer to ZPatterns 0.3.0, which I hope to
> release tomorrow.  0.2.0 doesn't have Specialists, for example.  0.3.0
> supports arbitrary persistent propertysheets, and has a well-fleshed out
> API (compared to earlier versions, anyway) for creating attribute
providers
> and sheet providers.

Excellent!

Kevin