[Zope-dev] ZPatterns Image Archive Project

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 08:59 PM 3/30/01 -0800, Michael R. Bernstein wrote:
> >
> >The terminology I'm using is ArchiveImage (for the 'Image'
> >class) and RackImage (for the 'Rendering' class).
> 
> I'd recommend a name change for RackImage, at least at the Specialist
> level.  If you don't like Renderings, then maybe RenderedImages,
> ActualImages, or some such.  Specialist names should reflect the *purpose*
> of a thing in the application rather than the nature of the thing itself.

Ah. That makes sense. Ok, so now my RackImage class is being
stored in a defaultRack of a Renderings Specialist contain
within the main ArchiveImages Specialist.

> >I think that different sizes would have the same behavioural
> >characteristics (simply an image file, really), but am less
> >sure about storage. My application will attempt to store all
> >the renderings in the ZODB, but if I want this to be
> >reusable, I have to assume that someone (including me) might
> >want to store the image data on the FS instead. If it's
> >going to be stored on the FS, it would be natural to dump
> >different sizes into separate directories, or even separate
> >partitions.
> 
> This can still be accomplished with a single specialist, if your 'id'
> format contains the necessary information to distinguish between image
> sizes/types.  If a user of your framework wants to seperate the storage,
> they can create more than one rack and have the specialist distinguish
> between them using the contents of the 'id'.  It's best to keep
> implementation simple in the reference implementation of a framework.

Ok.

> >I was thinking of a manage_upload method on the
> >ArchiveImage, that iterated through a list of sizes and used
> >an external method that imports PIL to resize the image
> >data, then passes the resized image data into the RackImage
> >manage_upload method.
> >
> >Does that seem reasonable?
> 
> It seems to me that sizing renderings should be the responsibility of the
> Renderings specialist.  That is, the ArchiveImage upload method would look
> something like this:
> 
> for imageKind in ('fullsize','thumbnail'):
>     Renderings.setRenderingFor(self,imageKind,imageData)
> 
> The setRenderingFor method would take the ArchiveImage's id, tack the
> imagekind onto it, and either retrieve the current image or create a new
> one, then re-size the image according to your rules for what size fullsize
> or thumbnail is, and pass it to the current or new rendered image object.
> (A counterpart method, getRenderingFor(archiveImage,imageKind) would do a
> similar id transformation to retrieve a rendering when called by the
> ArchiveImage's getRendering() method.)
> 
> Of course, this means that the Renderings specialist has to know what
> sizes different size names mean, and that ArchiveImages have to know the
> possible sizes.  Such knowledge being spread across two specialists means
> there's a specialist missing: RenderingKinds.
>
> [snip RenderingKinds as a sub-specialist of Renderings]
> 
> Although, it may be in your framework that ArchiveImages are responsible
> for knowing which kinds of renderings they should have, and the
> RenderingKinds specialist will simply deal with implementation details such
> as how each kind is sized and which rack they're stored in within the
> Renderings specialist.
> 
> By the way, RenderingKinds is a sort of specialist that hasn't been
> discussed much outside of the apps Ty and I work with - the "constant"
> Specialist, one which contains application configuration or metadata rather
> than "content".  Oftentimes it's handy to simply base a Specialist on a
> TinyTable or similar product in order to set up configuration of constant
> items like RenderingKinds.
> [snip]
> Now, you could make a RenderingKind class that uses this data to resize an
> image.  That is RenderingKind would have a sizeImage(imageData) method that
> returned a new image of the appropriate size.  It could also have a
> rackname attribute which would tell the Renderings specialist which rack an
> image of that kind should be stored in.  The user of the application could
> reconfigure at will by changing the contents of the TinyTable.
> 
> This might be all that RenderingKind objects do in the application - resize
> images and say where to put them.  But over time, you might find additional
> uses for them.  Like for example if you had certain rules about which kinds
> of renderings should be created for certain types of ArchiveImages.

Ok, using a RenderingKinds does seem like the way to go
here, since I eventually want renderings to be created using
different file formats (gif, jpeg) based on whether the
image is color or b&w (set as a property on ArchiveImage).

But I'm confused a bit:

It seems as though the manage_upload method is supposed to
hand off the image data to RenderingKinds, which in turn
either replaces the image data in existing Renderings, or
creates new ones, by iterating through the rows in the
TinyTable.

In turn, are RenderingKinds *also* responsible for returning
the appropriate Rendering based on a 'size' attribute? or
are ArchiveImages supposed to access Renderings directly to
find whatever Renderings exist for them?  Which SPecialist
now has a getRenderingFor(archiveImage,imageKind) method?

I can also see a problem with the following situation: after
several Archive images are created along with their
appropriate Renderings, the configuration information in the
TinyTable is changed, with new sizes added, and existing
sizes deleted or edited.

I would not expect the entire image database to be resized
and new sizes created automatically, so the data in the
Renderings Specialist would be out of sync with the sizing
meta-data, with Renderings possibly 'orphaned', and other
Renderings 'missing'

I *think* that these problems can be avoided, if the
Renderings Specialist is still responsible for reporting
what Renderings an ArchiveImage *has* (and possibly what
their dimensions are), and the RenderingKinds Specialist is
responsible for removing orphan renderings and creating
missing Renderings when the Image is either uploaded again
or 'refreshed'.

How would you reccomend handling this?

Thanks, Michael Bernstein.