The problem arises from the fact that we should be able to put a product object into multiple category folderish objects without actually **duplicating** it: if a product goes under the Categories A and B and when we delete the product from its parent Category A, it should be also deleted from the Category B. The same logic should also apply when we modify the object. It's much like creating a reference to an object instead of actually deep-copying it when we copy a product from one category to another.
I thought about putting all product objects into a single root category ( self-catalogging and BTreeFolderish ) and make subcategories transparent:
/Bookstore - root category /aBook - a product object /Thriller - subcategory ( transparent folderish ) /Romance - subcategory ( transparent folderish ) /Romance/Sheldon - sub-subcategory (transparent folderish, will this nested subcategories work? not sure. )
Notes on this: Transparent Folders are not needed for this to work as you describe below. Aquisition is a natural property of folderish objects in Zope. What's special about Transparency is that their contents look like they're in the folder's parent. (This might allow you to organize your objects but make them available on the lower level.) Transparent Folders are known performance issues, however.
We can visit the aBook object taking advantage of acquisition:
- /Bookstore/aBook - /Bookstore/Thriller/aBook - /Bookstore/Romance/aBook - /Bookstore/Romance/Sheldon/aBook
Will this work without any problems? What would be the easiest way to implement this? ( Without relying on RDBMS like MySQL , of course :-)
You can do this as long as you're not relying on folder contents to find content. A few approaches to consider: - use CMF and make your categories Portal Topics on some metadata. (One of the newer implementations, though, as the original is said to be killer slow.) - use regular Zope and catalog queries on a custom attibute (of metadata) for your categories. - use maxm's Relation product, or possibly Portable Hole, a similar product. - you might also put all your objects on a low level and look at them through acquisition, as you describe. I would probably make categories folderish objects that filter what they acquire. --jcc