[Zope] Merits of a photo class?

[chas]

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