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

[Steve Spicklemire]

Thanks Roche!

>>>>> "RC" == RC Compaan <sparroy@adept.co.za> writes:

    RC> Hi Steve

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

Ahh.. alas Playground is Win only (if I'm thinking correctly that it's
the software that came in Coad's book), and I loaned tbe book and CD
to someone else ... grrrr... ;-)

    RC> Take the Customer with Address property example: I create
    RC> Customer and Address Dataskins.  For Customer I have an
    RC> external method setAddress which sets the Address property of
    RC> my Customer object and this is how I would create a new
    RC> Customer: newCustomer = customerRack.newItem( CustomerCounter
    RC> ) newAddress = addressRack.newItem( AddressCounter )
    RC> newCustomer.setAddress( newAddress )

    RC> I prefer the simplicity this brings when I have to access the
    RC> properties of a Customer (without having to call a getter each
    RC> time I need an address): myCustomer.Address.Street

    RC> This also maps quite simply to SQL storage.

    RC> So although instances of Address are properties of Customer
    RC> they live on their own Rack and instances of Customer simply
    RC> refers to their Address through assignment.

Thanks... is that working between transactions? It has me a little
confused.  I've been snooping through the implementation of ZPatterns
for a clue.... and it looks to me like:

 a) the data manager for a DataSkin is a non-persistent attribute.
    (self._v_dm_). I think this means that it needs to be set
    somehow in every Zope transaction before you can do much of
    anything with the instance.

 b) For Rack mounted DataSkins this should happen when the item is
    retrieved from the Rack, and basically should be set to the Rack
    itself.

 c) If an object is set as an attribute of another DataSkin won't
    its data manager be lost at the end of the transaction?
    How does it find its rack again at the next transaction?

 I too like the simplicity of setting attributes rather than
 saving IDs, and that may lead me to experiement with the
 folder/customizer stuff.... but right now I'm still doing
 specialists/racks ( for some reason... that's where I started! )

    RC> With Container/Content type objects I do roughly the same - I
    RC> have setContainer methods for the Content objects.

So most of your objects are defined in Python products, or are these
methods ExternalMethods?

thanks!
-steve

    RC> Roché