Re: [Zope-dev] ZPatterns Image Archive Project
"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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns Image Archive Project
"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 to be able to give it > methods and to be able to distribute the class as part of the framework. Is that strictly neccessary, or can I just have a few Python Scripts in the RenderingKind specialist? Won't those work just as well? BTW, I thought that with the setup I described, I should be able to access the settings data through the web, ie: http://myserver.com/ArchiveImages/RenderingKinds/thumbnail/ where RenderingKinds has an index_html has a in it. But this fails, and reports a non-existent variable 'maxdimension'. Obviously I'm doing something wrong, but I don't know what. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns Image Archive Project
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns Image Archive Project
At 05:08 PM 4/1/01 -0700, Michael R. Bernstein wrote: > >Now, am I correct in assuming that the 'sizes' TinyTable >should be in the RenderingKinds Specialist? Yes. >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 to be able to give it methods and to be able to distribute the class as part of the framework. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns Image Archive Project
"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 base a Specialist on a > TinyTable or similar product in order to set up configuration of constant > items like RenderingKinds. Consider the TinyTable data below: > > Columns: name:string scaling:float width:int height:int rackname:string > > "fullsize",1.0,0,0,"bigimages" > "halfsize",0.5,0,0,"bigimages" > "thumbnail",0.0,64,64,"thumbnails" In my application, I'm only interested in specifying the 'maximum dimension' in any direction. This seems to work better generally, because it accounts automatically for images that are landscape or portrait oriented. So my TinyTable only has two columns: Columns: name:string maxdimension:int > The RenderingKinds specialist would have a single rack, which uses > SkinScript to pull in the data from the TinyTable (WITH > theTinyTable[self.id] COMPUTE scaling,width,height,rackname). The SkinScript (which I placed in the RenderingKinds Specialist, not in it's defaultRack) has the following line in it: WITH sizes[self.id] COMPUTE maxdimension I eliminated the 'rackname' column, because you reccomended that all Renderings(RackImages) be stored in the same Rack, for simplicity. This also seems the more flexible approach (ie. I don't have to create management screens to add and delete racks when the sizes change), so there is less 'hardwiring'. Now, am I correct in assuming that the 'sizes' TinyTable should be in the RenderingKinds Specialist? 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? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns Image Archive Project
"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 Renderings, then maybe RenderedImages,
> ActualImages, or some such. Specialist names should reflect the *purpose*
> of a thing in the application rather than the nature of the thing itself.
Ah. That makes sense. Ok, so now my RackImage class is being
stored in a defaultRack of a Renderings Specialist contain
within the main ArchiveImages Specialist.
> >I think that different sizes would have the same behavioural
> >characteristics (simply an image file, really), but am less
> >sure about storage. My application will attempt to store all
> >the renderings in the ZODB, but if I want this to be
> >reusable, I have to assume that someone (including me) might
> >want to store the image data on the FS instead. If it's
> >going to be stored on the FS, it would be natural to dump
> >different sizes into separate directories, or even separate
> >partitions.
>
> This can still be accomplished with a single specialist, if your 'id'
> format contains the necessary information to distinguish between image
> sizes/types. If a user of your framework wants to seperate the storage,
> they can create more than one rack and have the specialist distinguish
> between them using the contents of the 'id'. It's best to keep
> implementation simple in the reference implementation of a framework.
Ok.
> >I was thinking of a manage_upload method on the
> >ArchiveImage, that iterated through a list of sizes and used
> >an external method that imports PIL to resize the image
> >data, then passes the resized image data into the RackImage
> >manage_upload method.
> >
> >Does that seem reasonable?
>
> It seems to me that sizing renderings should be the responsibility of the
> Renderings specialist. That is, the ArchiveImage upload method would look
> something like this:
>
> for imageKind in ('fullsize','thumbnail'):
> Renderings.setRenderingFor(self,imageKind,imageData)
>
> The setRenderingFor method would take the ArchiveImage's id, tack the
> imagekind onto it, and either retrieve the current image or create a new
> one, then re-size the image according to your rules for what size fullsize
> or thumbnail is, and pass it to the current or new rendered image object.
> (A counterpart method, getRenderingFor(archiveImage,imageKind) would do a
> similar id transformation to retrieve a rendering when called by the
> ArchiveImage's getRendering() method.)
>
> Of course, this means that the Renderings specialist has to know what
> sizes different size names mean, and that ArchiveImages have to know the
> possible sizes. Such knowledge being spread across two specialists means
> there's a specialist missing: RenderingKinds.
>
> [snip RenderingKinds as a sub-specialist of Renderings]
>
> Although, it may be in your framework that ArchiveImages are responsible
> for knowing which kinds of renderings they should have, and the
> RenderingKinds specialist will simply deal with implementation details such
> as how each kind is sized and which rack they're stored in within the
> Renderings specialist.
>
> 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 base a Specialist on a
> TinyTable or similar product in order to set up configuration of constant
> items like RenderingKinds.
> [snip]
> Now, you could make a RenderingKind class that uses this data to resize an
> image. That is RenderingKind would have a sizeImage(imageData) method that
> returned a new image of the appropriate size. It could also have a
> rackname attribute which would tell the Renderings specialist which rack an
> image of that kind should be stored in. The user of the application could
> reconfigure at will by changing the contents of the TinyTable.
>
> This might be all that RenderingKind objects do in the application - resize
> images and say where to put them. But over time, you might find additional
> uses for them. Like for example if you had certain rules about which kinds
> of renderings should be created for certain types of ArchiveImages.
Ok, using a RenderingKinds does seem like the way to go
here, since I eventually want renderings to be created using
different file formats (gif, jpeg) based on whether the
image is color or b&w (set as a property on ArchiveImage).
But I'm confused a bit:
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
Re: [Zope-dev] ZPatterns Image Archive Project
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 have no
>> real behavioral differences and can be implemented with the same class and
>> storage characteristics.
>
>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 Renderings, then maybe RenderedImages,
ActualImages, or some such. Specialist names should reflect the *purpose*
of a thing in the application rather than the nature of the thing itself.
>I think that different sizes would have the same behavioural
>characteristics (simply an image file, really), but am less
>sure about storage. My application will attempt to store all
>the renderings in the ZODB, but if I want this to be
>reusable, I have to assume that someone (including me) might
>want to store the image data on the FS instead. If it's
>going to be stored on the FS, it would be natural to dump
>different sizes into separate directories, or even separate
>partitions. Two years from now, this web application could
>contain around 300 Gb of images (current prices on that much
>storage are about $1,000 for ten 30 Gb hard-drives, so I'm
>not too worried on that score).
This can still be accomplished with a single specialist, if your 'id'
format contains the necessary information to distinguish between image
sizes/types. If a user of your framework wants to seperate the storage,
they can create more than one rack and have the specialist distinguish
between them using the contents of the 'id'. It's best to keep
implementation simple in the reference implementation of a framework.
>> >That's what I meant, sorry. The RackImages need to appear to
>> >be attributes of the ZClass, and I'll use SkinScripts to
>> >accomplish that.
>>
>> That's really only practical if you have a fixed set of rendering types and
>> names, but it'll work for retrieval. It won't really help you with
>> creation and assignment, though. I'd suggest specialized methods on Image
>> which delegate to the Renderings specialist.
>
>I was thinking of a manage_upload method on the
>ArchiveImage, that iterated through a list of sizes and used
>an external method that imports PIL to resize the image
>data, then passes the resized image data into the RackImage
>manage_upload method.
>
>Does that seem reasonable?
It seems to me that sizing renderings should be the responsibility of the
Renderings specialist. That is, the ArchiveImage upload method would look
something like this:
for imageKind in ('fullsize','thumbnail'):
Renderings.setRenderingFor(self,imageKind,imageData)
The setRenderingFor method would take the ArchiveImage's id, tack the
imagekind onto it, and either retrieve the current image or create a new
one, then re-size the image according to your rules for what size fullsize
or thumbnail is, and pass it to the current or new rendered image object.
(A counterpart method, getRenderingFor(archiveImage,imageKind) would do a
similar id transformation to retrieve a rendering when called by the
ArchiveImage's getRendering() method.)
Of course, this means that the Renderings specialist has to know what
sizes different size names mean, and that ArchiveImages have to know the
possible sizes. Such knowledge being spread across two specialists means
there's a specialist missing: RenderingKinds. This may be a sub-specialist
of Renderings, or a peer of Renderings within ArchiveImages. If a
sub-specialist of Renderings, Renderings must expose a method to retrieve
the sizes, and the upload method above would look like this instead:
for imageKind in Renderings.getRenderingKindsFor(self):
Renderings.setRenderingFor(self,imageKind,imageData)
Although, it may be in your framework that ArchiveImages are responsible
for knowing which kinds of renderings they should have, and the
RenderingKinds specialist will simply deal with implementation details such
as how each kind is sized and which rack they're stored in within the
Renderings specialist.
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 base a Specialist on a
TinyTable or similar product in order to set up configuration of constant
items like RenderingKinds. Consider the TinyTable data below:
Columns: name:string scaling:float width:int height:int rackname:string
"fullsize",1.0,0,0,"bigimages"
"halfsize",0.5,0,0,"bigimages"
"thumbnail",0.0,64,64,"thumbnails"
The RenderingKinds specialist would have a single rack, which uses
SkinScript to
Re: [Zope-dev] ZPatterns Image Archive Project
"Phillip J. Eby" wrote: > > At 07:30 PM 3/30/01 -0800, Michael R. Bernstein wrote: > > > >Well, I want to store several versions of each image. Let's > >take a simplified case where I want the original image and a > >thumbnail, both of which need to appear as subobjects of the > >ZClass with the meta-data. > > 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 have no > real behavioral differences and can be implemented with the same class and > storage characteristics. The terminology I'm using is ArchiveImage (for the 'Image' class) and RackImage (for the 'Rendering' class). I think that different sizes would have the same behavioural characteristics (simply an image file, really), but am less sure about storage. My application will attempt to store all the renderings in the ZODB, but if I want this to be reusable, I have to assume that someone (including me) might want to store the image data on the FS instead. If it's going to be stored on the FS, it would be natural to dump different sizes into separate directories, or even separate partitions. Two years from now, this web application could contain around 300 Gb of images (current prices on that much storage are about $1,000 for ten 30 Gb hard-drives, so I'm not too worried on that score). > >If I store all the RackImages (originals and thumbnails) in > >one Rack, how do I differentiate between them, so that > >'/Archive/001/thumbnail' and 'Archive/001/original' show the > >appropriate images? It just seemed simpler to create a > >'thumbnail' Rack and an 'original' Rack. > > It sounds to me like you want an Images specialist and a Renderings > specialist, with the latter contained within the former (because Renderings > are only accessed by way of Images). Your Image class should have a > "getRendering(kind)" method which accesses the renderings specialist to > retrieve a rendering, and it can also have a __bobo_traverse__ method that > uses getRendering to allow traversal as you describe. This would still be > completely storage independent, since that's hidden in the Renderings > specialist. Likewise, when your Images create renderings, they'll need to > delegate the actual creation to the Renderings specialist. Thanks, that's *very* helpful. I'm not too certain how to accomplish the 'getRendering(kind)' and the '__bobo_traverse__' magic, But I'll cross that bridge a little later. > If you need different classes for different kinds of renderings, you'll > need multiple racks inside the Renderings specialist, but if renderings are > basically just a Zope Image object, you can just use a single Rack (and > make your id values something like '001_original', '002_thumbnail', etc. > and construct these in your getRendering() method). > > >That's what I meant, sorry. The RackImages need to appear to > >be attributes of the ZClass, and I'll use SkinScripts to > >accomplish that. > > That's really only practical if you have a fixed set of rendering types and > names, but it'll work for retrieval. It won't really help you with > creation and assignment, though. I'd suggest specialized methods on Image > which delegate to the Renderings specialist. I was thinking of a manage_upload method on the ArchiveImage, that iterated through a list of sizes and used an external method that imports PIL to resize the image data, then passes the resized image data into the RackImage manage_upload method. Does that seem reasonable? Thanks, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns Image Archive Project
At 07:30 PM 3/30/01 -0800, Michael R. Bernstein wrote: >"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 out of curiousity, why do you want seperate racks for each size? Are >> they being stored in different ways or have different behavioral >> requirements (e.g. different classes) apart from their size? If not, there >> is probably no reason to have multiple racks. > >Well, I want to store several versions of each image. Let's >take a simplified case where I want the original image and a >thumbnail, both of which need to appear as subobjects of the >ZClass with the meta-data. 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 have no real behavioral differences and can be implemented with the same class and storage characteristics. >If I store all the RackImages (originals and thumbnails) in >one Rack, how do I differentiate between them, so that >'/Archive/001/thumbnail' and 'Archive/001/original' show the >appropriate images? It just seemed simpler to create a >'thumbnail' Rack and an 'original' Rack. It sounds to me like you want an Images specialist and a Renderings specialist, with the latter contained within the former (because Renderings are only accessed by way of Images). Your Image class should have a "getRendering(kind)" method which accesses the renderings specialist to retrieve a rendering, and it can also have a __bobo_traverse__ method that uses getRendering to allow traversal as you describe. This would still be completely storage independent, since that's hidden in the Renderings specialist. Likewise, when your Images create renderings, they'll need to delegate the actual creation to the Renderings specialist. If you need different classes for different kinds of renderings, you'll need multiple racks inside the Renderings specialist, but if renderings are basically just a Zope Image object, you can just use a single Rack (and make your id values something like '001_original', '002_thumbnail', etc. and construct these in your getRendering() method). >That's what I meant, sorry. The RackImages need to appear to >be attributes of the ZClass, and I'll use SkinScripts to >accomplish that. That's really only practical if you have a fixed set of rendering types and names, but it'll work for retrieval. It won't really help you with creation and assignment, though. I'd suggest specialized methods on Image which delegate to the Renderings specialist. >> >Where do I put the separate Racks? do I create a specialist >> >for each Rack (seems unneccessary) or do I put several Racks >> >in the same Specialist? >> >> Several in the same, if they are providing objects which fill the same role >> in your overall application. > >And do the RackImages Racks go into the same Specialist as >the ZClass Rack? Sorry, I didn't realize you had two different notions - the abstract notion of an Image and the concrete notion of its Rendering. So there are two specialists, and (at least) two racks. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns Image Archive Project
"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 out of curiousity, why do you want seperate racks for each size? Are > they being stored in different ways or have different behavioral > requirements (e.g. different classes) apart from their size? If not, there > is probably no reason to have multiple racks. Well, I want to store several versions of each image. Let's take a simplified case where I want the original image and a thumbnail, both of which need to appear as subobjects of the ZClass with the meta-data. If I store all the RackImages (originals and thumbnails) in one Rack, how do I differentiate between them, so that '/Archive/001/thumbnail' and 'Archive/001/original' show the appropriate images? It just seemed simpler to create a 'thumbnail' Rack and an 'original' Rack. > >I realize that I need to tie the Racks together in the > >specialist using SkinScripts > > SkinScript doesn't do anything to tie racks together or to a Specialist - > it's just a way of describing where the data comes from/goes to for a > particular Rack. That's what I meant, sorry. The RackImages need to appear to be attributes of the ZClass, and I'll use SkinScripts to accomplish that. > >Where do I put the separate Racks? do I create a specialist > >for each Rack (seems unneccessary) or do I put several Racks > >in the same Specialist? > > Several in the same, if they are providing objects which fill the same role > in your overall application. And do the RackImages Racks go into the same Specialist as the ZClass Rack? > >The DTML I am using to instantiate RackImages in the Rack > >for example, is as follows: > > > > > > > > > > > > > >But this code only works for a Rack named defaultRack, which > >I can obviously only have one of. > > Just use the name of the rack, e.g.: > > , etc. Ok, thanks! That works (Duh). Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns Image Archive Project
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 out of curiousity, why do you want seperate racks for each size? Are they being stored in different ways or have different behavioral requirements (e.g. different classes) apart from their size? If not, there is probably no reason to have multiple racks. >I realize that I need to tie the Racks together in the >specialist using SkinScripts SkinScript doesn't do anything to tie racks together or to a Specialist - it's just a way of describing where the data comes from/goes to for a particular Rack. >Where do I put the separate Racks? do I create a specialist >for each Rack (seems unneccessary) or do I put several Racks >in the same Specialist? Several in the same, if they are providing objects which fill the same role in your overall application. >If the latter, I'm unsure how to use DTML or PythonScripts >to specify which Rack to create a new item in. > >The DTML I am using to instantiate RackImages in the Rack >for example, is as follows: > > > > > > >But this code only works for a Rack named defaultRack, which >I can obviously only have one of. > >Any advice on this would be greatly appreciated. > Just use the name of the rack, e.g.: , etc. Racks are subobjects of their specialists. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
