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