[Zope-dev] Object hierarchy in RIPP

[Phillip J. Eby]

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.

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.

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__.  :)

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.