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