This is mostly directed at Philip Eby, but I'm sure there are others out there who are trying to work RIPP into their design patterns. Basically, all of my Zope development has been through-the-web. I'm quite comfortable with using ZClasses, DTML, PythonMethods and ExternalMethods to get the job done. Something I'm unclear on with ZPatterns is how to do some of the things that I currently do with ZClasses. Here is a specific example: 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. Now let's say I want to create new product objects that allow me to do the same kinds of things, but I also want a propertysheet that comes from an RDBMS (to keep track of inventory, let's say). Would I pretty much store things the same way as I have been and just work in a separate SheetProvider to take care of the inventory propertysheet? Or is there some way in which I would store things on a Rack and yet still have the traversal structure that I want? Understanding the RIPP way of tackling a problem like this would really help me out... TIA, Kevin http://www.byproducts.com - Humor and Novelties
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.
participants (2)
-
Kevin Dangoor -
Phillip J. Eby