At 12:31 PM 9/13/99 +1000, Darran Edmundson wrote:
Sidenote, if you're cataloging a lot of images, you might find it easier to create a zclass called, say, "catalogedimage" with 2 properties : 'mycaption' and 'myimage'. Then you wouldn't have to worry about existence of a property, just the value. But maybe I'm just overboard with zclasses lately so ymmv.
I wondered about this. I've yet to use Zclasses, using only the standard objects that come with Zope.
My advice : use them now. Give it a shot. Perhaps it won't work out but it's better to learn about them now than 2 months down the line. Once I found out how easy they are and how flexible, I went back and rewrote almost all my code to use them - it's much more scalable (for my needs anyway). They could potentially save you alot of time if your project is going to grow more complex. There are a few quirks in more complex zclasses (see my other queries about adding zsql methods and the problems with adding zclasses to zclasses ... but as more and more people come across these, it becomes easier for you.) Ok, going to your example :
I had thought of trying to implement a photo class that had several key features:
- a caption, photographer, photo_date, photo_location, and keywords property - the ability to store several image objects (differing resolutions of same image) - the ability to render at various resolutions - buttons to select current rendering resolutions.
Do you see the merit in such a class?
Definitely. It would be one hell of a headache to do this any other way. The best thing about zclasses is that if you find after 2 years that you also need to add a new property (eg. cost for purchase) then you can update the class and all instances will be automatically updated. Ditto for methods (eg. adding a method for "purchase_this") The big question here though is the scalability of zodb for a photo-catalog. On the MySQL list, the general consensus is that keeping files on the filesystem is the way to go (as opposed to storing GB's of images in the DB). However, Zope saves you from having to deal with extracting the image from the DB (which is real hassle) so that's no longer an issue. Personally, I think scalability is still better keeping photos outside... you could keep the photos on several disks or servers all fed from the one zope server. I may be wrong. But even if you're just including the URL's to the images, the zclass will still be a saviour. Sidenote : one reason *to* keep the images in the Zope ODB is that you could assign privileges - good if you're charging for view.
If so, any tips on implementing this beast, specifically the containment of an arbitrary number of images.
This is something that really needs to be spelled out in black and white in the zclasses tutorial. (The tutorial is excellent for getting you up and running with the basics of zclasses but beyond that, Kevin's kmnews product *is* the best reference for learning about advanced zclass concepts.) Anyway, to create a zclass that can contain other zclass's, just make sure that the container zclass is based on the ObjectManager class. (don't be scared by the term ObjectManager - it is as simple as it sounds - it stores objects. It allows you to create a zclass that can contain other zclasses.) Hope that helps get you off the ground - email back if further problems, lord knows I had my share fair. chas