[Zope-dev] ZPatterns Image Archive Project

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 01:45 PM 4/1/01 -0700, Michael R. Bernstein wrote:
> >
> >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.
> 
> [shudder].  No, not at *all*.  The calling pattern goes like this:
> 
> anArchiveImage.upload:
>     for kind in RenderingKinds.getKindsFor(self):
>         Renderings.setRenderingFor(self,kind,data)
> 
> The ArchiveImage is responsible for knowing the image data.  The
> RenderingKinds specialist is responsible for knowing what renderings should
> be made for an ArchiveImage.  The Renderings specialist is responsible for
> creating and storing a rendering, given an image and a kind of rendering to
> be made.  However, it may ask the kind object for dimensions or other
> assistance in actually creating the rendering.
> [snip]
> Don't think "RenderingKinds replaces the image data in existing
> Renderings", because that's "meddleware" - objects meddling in each others'
> business.  Renderings is responsible for renderings.  RenderingKinds is
> only responsible for knowing about *kinds*.

Ok. RenderingKinds (in my implementation) iterates through
the TinyTable, and returns a list of Kind objects.

Then, the ArchiveImage sends the list of Kinds to
Renderings. Renderings, in turn, iterates through the list
(grabbing dimension info from the Kind object) and creates
each Rendering appropriately.

> >In turn, are RenderingKinds *also* responsible for returning
> >the appropriate Rendering based on a 'size' attribute?
> 
> No.  RenderingKinds are responsible only for knowing about *kinds*, not the
> details of a particular image.  Thus, it makes sense for RenderingKinds to
> implement rules about what renderings an image *should* have, but the ones
> it *does* have are the domain of the image itself (but delegated to the
> Renderings specialist for actual implementation).

Ok.

> >are ArchiveImages supposed to access Renderings directly to
> >find whatever Renderings exist for them?  Which Specialist
> >now has a getRenderingFor(archiveImage,imageKind) method?
> 
> Renderings.  ArchiveImage should have getRendering(imageKind) which then
> calls Renderings.getRenderingFor(self,imageKind).

Mmm. I think I see, but you didn't actually answer the first
of the two questions. More below.

> >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

Here's what I meant:

Should ArchiveImage have a getRenderings(self) which in turn
calls Renderings.getRenderingsFor(self)? This should (I
think) return a list of Kinds that Renderings has stored for
a particular ArchiveImage.

> >responsible for removing orphan renderings and creating
> >missing Renderings when the Image is either uploaded again
> >or 'refreshed'.
> >
> >How would you reccomend handling this?
> 
> That depends on what the requirements are.  If you need to implement this,
> then the sensible place to do it is probably in the RenderingKind objects
> and RenderingKinds specialist.  That is, adding a RenderingKind might
> include the option to go through and create the missing renderings, and
> deleting or altering one might similarly prompt for updates.

Um. You mean for all ArchiveImages? What I meant is that you
would be able to tell an individual ArchiveImage to either
upload new data or just 'refresh' itself (manually), and a
process substantially similar to the ArchiveImage creation
process would create missing Renderings, and overwrite the
ones that already existed (just in case their dimensions
changed), and delete Renderings that no longer had an
equivalent RenderingKind. All for the individual image, not
for all images.

I can later add a batch interface to trigger this on X
images at a time, to avoid causing the server to thrash.

Does this seem reasonable?

Thanks for the help,

Michael Bernstein.