Roché wrote:

>Steve Spicklemire wrote:
>>   If I explicitly store a Bar object as an Attribute of a DataSkin then
>>   what happens if the original Bar is removed from its Specialist's
>>   Rack? Does the Bar I store still refer to the original Rack as its
>>   DataManager? So.. does a Rack sometimes have 'clients' that are not
>>   really in the Rack at all? Or perhaps I misunderstood the discussion,
>  >  and the Address wasn't really a DataSkin at all?  Also.. assuming
>>   that all works, do I have to do anything special, or carefully to be
>>   sure that the persistence machinery doesn't incur lots of expensive
>>   attribute fetching if I don't explicitly refer to those attributes,
>>   but have the DataSkin as a directly set attribute of another
>>   DataSkin?
>Before I started building Apps with ZPatterns I built a object/relational
>access layer in Delphi for my applications which enables me to create pure
>objects in my problem domain and delegate all data management to the the
>access layer.  I *think* this is one of the things ZPatterns wants to do as
>Take the Customer with Address property example:
>I create Customer and Address Dataskins.  For Customer I have an external
>method setAddress which sets the Address property of my Customer object and
>this is how I would create a new Customer:
>   newCustomer = customerRack.newItem( CustomerCounter )
>   newAddress = addressRack.newItem( AddressCounter )
>   newCustomer.setAddress( newAddress )
>I prefer the simplicity this brings when I have to access the properties of
>a Customer (without having to call a getter each time I need an address):
>   myCustomer.Address.Street
>This also maps quite simply to SQL storage.
>So although instances of Address are properties of Customer they live on
>their own Rack and instances of Customer simply refers to their Address
>through assignment.
>With Container/Content type objects I do roughly the same - I have
>setContainer methods for the Content objects.

Me thinks that what we all need is a guide to implementing object 
connections for different object relationships and patterns. Perhaps 
something like this (view with monospaced font):

   Object relationship    |   
        (Pattern)         |  Implementation
      1       1           | Add prop to A: b_id
    A --------- B         | In A call Bs (Specialist of B): my_b = 
      n       1           | Add prop to B: a_id
    A --------- B         | Add method to Bs (Specialist of B): getBsForA(a_id)
                          | In A call Bs: my_b_list = Bs.getBsForA(a_id)
      n       n           | ?
    A --------- B         |
     n   [XOR A] 1        | Add Specialist Xs implementing role of A and B
  A  -------------        | Add prop to C: x_id
     n   [XOR A] 1  C     | In A, B call Xs: my_x = Xs.getItem(x_id)
  B --------------        |
(Participant-Transaction)| (A and B - Participants, C - Transaction)
    [XOR A] 1  n          | Add prop to B, C: a_id
    ------------ B        | In B, C call As (Specialist of A): my_a = 
  A [XOR A] 1  n          |
    ------------ C        | (can't do reverse connection?)

Does anyone think this would be useful? Can we get the experts to 
expand/correct/verify this? Obviously more relationship types need to 
be added, and also some extra information is needed (such as who's 
responsible to set the id attributes and how, when and how reverse 
connections are done, etc.).

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 - )

Reply via email to