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.
"Phillip J. Eby" wrote:
At 05:08 PM 4/1/01 -0700, Michael R. Bernstein wrote:
I'm also assuming that RenderingKinds' defaultRack is set to
use 'ZPatterns: DataSkin' and be set to load by accessing
the 'id' attribute. Is this correct?
Well, I would create a "RenderingKind" ZClass, so as
"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
At 08:59 PM 3/30/01 -0800, Michael R. Bernstein wrote:
"Phillip J. Eby" wrote:
Aha. I think I understand what you're doing now. You have an "Image" and
you have a "Rendering". Two classes, different behaviors. I'm assuming
that originals and thumbnails and whatever other renderings exist
"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
"Phillip J. Eby" wrote:
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
"Phillip J. Eby" wrote:
At 05:27 PM 3/30/01 -0800, Michael R. Bernstein wrote:
Now I am working on a ArchiveImage ZClass that holds 'meta'
information about an image, such as the description, a date,
and keywords.
I want to have one Rack for each image size that I want to
store.
Just
