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.