[Zope-dev] ZPatterns Image Archive Project

[Phillip J. Eby]

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.  

Don't think "iterating through rows in the TinyTable".  Outside
RenderingKinds, nobody knows there's a TinyTable.  *You* don't know there's
a TinyTable, because the application integrator might decide to do it with
a table in an SQL database or a ZODB folder.

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

This is probably the hardest part of ZPatterns design for people to learn.
Ironically, it's nothing more than the most fundamental of O-O design
principles.  Everybody thinks they know O-O, incredibly few do.  I was
doing O-O for almost *fifteen years* before I realized I wasn't even close
to doing it right at this level of design!


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


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


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

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.