Implementing [XOR A] 1 object connections in ZPatterns
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"
Hi Itai,
"Itai" == Itai Tavor <itai@optusnet.com.au> writes:
... Itai> The 2nd way seems to go better with OO principles - all Itai> handling of photos is delegated to the Photos Specialist and Itai> the Product doesn't care if the photo exists or not, or Itai> where it comes from. But it also increases complexity in Itai> Photos, because I need to implement an efficient way to Itai> retrieve photos (with a Catalog, or SQL searches), and Itai> because it introduces the photo_key. Storing photo_id in Itai> Product eliminates these complexities, but it moves some of Itai> the responsibility for managing photos into Product. Hmmm.. it seems to me that it makes more sense for the Product to know the id of the Photo that *it* needs to display itself than for the Photo to have to know that it belongs to a particular Product. Also.. I can imagine that the Photo class might be useful for lots of other things besides Products, and how would you teach it what type of object it belongs to? Just my $0.02. ;-) -steve
Steve Spicklemire wrote:
"Itai" == Itai Tavor <itai@optusnet.com.au> writes:
...
Itai> The 2nd way seems to go better with OO principles - all Itai> handling of photos is delegated to the Photos Specialist and Itai> the Product doesn't care if the photo exists or not, or Itai> where it comes from. But it also increases complexity in Itai> Photos, because I need to implement an efficient way to Itai> retrieve photos (with a Catalog, or SQL searches), and Itai> because it introduces the photo_key. Storing photo_id in Itai> Product eliminates these complexities, but it moves some of Itai> the responsibility for managing photos into Product.
Hmmm.. it seems to me that it makes more sense for the Product to know the id of the Photo that *it* needs to display itself than for the Photo to have to know that it belongs to a particular Product. Also.. I can imagine that the Photo class might be useful for lots of other things besides Products, and how would you teach it what type of object it belongs to?
Actually, my Photo object really is used for other things besides Products, which is where my problems with XOR connections come in... I myself prefer the first method (Product knowing the id of its Photo), but I've been bitten a lot recently by placing responsibilities outside the classes where they belong, so I'm trying hard to make sure I don't do it again.
Just my $0.02.
It's worth more than that to me :) -- 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"
participants (2)
-
Itai Tavor -
Steve Spicklemire