[Zope-dev] ZPatterns Image Archive Project

Phillip J. Eby pje@telecommunity.com
Fri, 30 Mar 2001 23:14:43 -0500


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.