>At 06:15 PM 10/12/00 +1100, Itai Tavor wrote:
>  >Hi,
>  >2. I want to store a list of products, and give each one an arbitrary
>>number of photos. I can use a Product ZClass, subclassed from
>>ObjectManager and store Image objects inside it. But what will happen
>>to these objects if I use this ZClass in a Rack? And how would I
>>handle storing the objects in SQL tables - I will need to somehow
>>turn each Image object into a table entry, and the same Generic
>>Attribute Provider will have to work with 2 SQL tables. Is there a
>>nice way of doing this? Or should I store the photos in a separate
>>ZClass and use it in another Rack in the Products Specialist?
>I would not suggest trying to go the ObjectManager route.  ZPatterns does
>not have a good way at present to map child objects into other databases.
>Instead, a more custom approach would be appropriate, where you have say an
>"images" attribute that is loaded/saved through SQL.  This has the
>downside, however, of being either resource intensive or computationally
>However, it'd probably be best of all to have a Photos specialist, with a
>getPhotosForProduct() method, addPhotoToProduct(), and so on.

Why would I want another Specialist for photos? Photos are just 
another attribute of a Product. They just happen to be stored 
separately, a distinction which I think should happen at the Rack 
level. I created my Products Specialist with 3 racks: 'defaultRack' 
for Product properties, 'photoRack' for photos, and 'priceRack' for 
product price options (every product can have multiple price options, 
so I don't store a price in the product properties). Then I can have 
methods in each Rack to deal with the specific object stored in it, 
and methods in the Specialist to handle the overall view. I can also 
have a SkinScript in the defaultRack to return a virtual Product 
object which includes a list of photo objects. Is there anything 
wrong with this?

>  >Actually, I can't put an Image object on a DataSkin, right? So
>>however I store it, it's going to have to be a my own custom Image
>>object subclassed from DataSkin...
>Not necessarily, it depends on your overall structure.  If you want to use
>standard Zope Image objects you may indeed want to subclass from DataSkin.

I do want to use the standard Zope Image object - it's got a lot of 
useful functions that I don't want to lose and I don't want to do the 
work of writing my own Image class and duplicating all those 
functions. But I don't know how to get the Image product to store in 
a DataSkin - or if it's possible at all. If I create a ZClass 
subclassing Image and DataSkin, would the image data automatically 
get stored in the DataSkin? Or do I have to override all methods 
dealing with storage in the object? Also, the Image __init__ methd 
requires a file - Image objects can't be created empty, but the 
DataSkin always creates new objects with no data, so I guess some 
overriding will be required to allow the object to function empty...

Itai Tavor                    "Je sautille, donc je suis."
C3Works    [EMAIL PROTECTED]              - Kermit the Frog

"If you haven't got your health, you haven't got anything"

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to