At 07:30 PM 3/30/01 -0800, Michael R. Bernstein wrote:
"Phillip J. Eby" wrote:
At 05:27 PM 3/30/01 -0800, Michael R. Bernstein wrote:
Now I am working on a ArchiveImage ZClass that holds 'meta' information about an image, such as the description, a date, and keywords.
I want to have one Rack for each image size that I want to store.
Just out of curiousity, why do you want seperate racks for each size? Are they being stored in different ways or have different behavioral requirements (e.g. different classes) apart from their size? If not, there is probably no reason to have multiple racks.
Well, I want to store several versions of each image. Let's take a simplified case where I want the original image and a thumbnail, both of which need to appear as subobjects of the ZClass with the meta-data.
Aha. I think I understand what you're doing now. You have an "Image" and you have a "Rendering". Two classes, different behaviors. I'm assuming that originals and thumbnails and whatever other renderings exist have no real behavioral differences and can be implemented with the same class and storage characteristics.
If I store all the RackImages (originals and thumbnails) in one Rack, how do I differentiate between them, so that '/Archive/001/thumbnail' and 'Archive/001/original' show the appropriate images? It just seemed simpler to create a 'thumbnail' Rack and an 'original' Rack.
It sounds to me like you want an Images specialist and a Renderings specialist, with the latter contained within the former (because Renderings are only accessed by way of Images). Your Image class should have a "getRendering(kind)" method which accesses the renderings specialist to retrieve a rendering, and it can also have a __bobo_traverse__ method that uses getRendering to allow traversal as you describe. This would still be completely storage independent, since that's hidden in the Renderings specialist. Likewise, when your Images create renderings, they'll need to delegate the actual creation to the Renderings specialist. If you need different classes for different kinds of renderings, you'll need multiple racks inside the Renderings specialist, but if renderings are basically just a Zope Image object, you can just use a single Rack (and make your id values something like '001_original', '002_thumbnail', etc. and construct these in your getRendering() method).
That's what I meant, sorry. The RackImages need to appear to be attributes of the ZClass, and I'll use SkinScripts to accomplish that.
That's really only practical if you have a fixed set of rendering types and names, but it'll work for retrieval. It won't really help you with creation and assignment, though. I'd suggest specialized methods on Image which delegate to the Renderings specialist.
Where do I put the separate Racks? do I create a specialist for each Rack (seems unneccessary) or do I put several Racks in the same Specialist?
Several in the same, if they are providing objects which fill the same role in your overall application.
And do the RackImages Racks go into the same Specialist as the ZClass Rack?
Sorry, I didn't realize you had two different notions - the abstract notion of an Image and the concrete notion of its Rendering. So there are two specialists, and (at least) two racks.