[Zope-dev] Implementing [XOR A] 1 object connections in ZPatterns

5 Dec 2000

      Hi,

Continuing the saga of my struggles with ZPatterns, I'm trying to 
work out the best way to implement an object that can be related to 
one of several other objects.

For example, I have a Product class. A Product can come in different 
colors, so I also have a Color class. Products can have two photos of 
the product - small and large. Colors can also have a photo, showing 
the product in that particular color. So, a Photo object can be a 
large product photo, a small product photo, or a color photo.

I can think of two ways to implement this:

1. Add small_photo_id, large_photo_id properties to Product, and 
photo_id property to Color. Then I do something like:

     Product.editInstanceForm:

     <dtml-if large_photo_id>
       <dtml-var "Photos.getItem(large_photo_id).viewInstance(...)">
     <dtml-else>
       <form action="selectLargePhoto" method="post">
       <dtml-var "Photos.selectPhotoSnippet(...)">
       </form>
     </dtml-if>

     <method>Product.selectLargePhoto</method>:

     photo_id = self.Photos.selectPhoto(REQUEST)
     self.propertysheets.Basic.manage_changeProperties(large_photo_id=photo_id)

2. Add owner_id, photo_key properties to Photo. Then use:

     Product.editInstanceForm:

     <dtml-var "Photos.selectPhotoForOwner(Photos, REQUEST, 
owner_id=id, photo_key='large')">

     Photos.selectPhotoForOwner:

     <dtml-let photo="defaultRack.getItemForKey(owner_id, photo_key)">
       <dtml-if photo>
         <dtml-var "photo.viewInstance(...)"
       <dtml-else>
         ...
         code for selecting/creating photo
         ...
     </dtml-let>

The 2nd way seems to go better with OO principles - all handling of 
photos is delegated to the Photos Specialist and the Product doesn't 
care if the photo exists or not, or where it comes from. But it also 
increases complexity in Photos, because I need to implement an 
efficient way to retrieve photos (with a Catalog, or SQL searches), 
and because it introduces the photo_key. Storing photo_id in Product 
eliminates these complexities, but it moves some of the 
responsibility for managing photos into Product.

Can anyone add anything on making the choice? Or maybe a 3rd way I 
haven't thought of?

Thanks,
Itai
-- 
Itai Tavor                    "Je sautille, donc je suis."
C3Works    itai@c3works.com              - Kermit the Frog

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