[Zope-dev] RE: ZPatterns, ObjectDomain, UML and all that.....

[RC Compaan]

Hi Steve

I'm also a babe in the woods when it comes to object modelling, but here's
my pennie's worth.  Since code generation was not really required in the
models I recently did for Zope Apps and the terrible exchange rate on the
South African Rand I decided to use to very light weight Playground
modelling tool.  I agree with Steve Alexander that Coad notation serves
ZPatterns *better* and this is exactly what Playground uses.

>  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
well.

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.

Roché