RE: ZPatterns, ObjectDomain, UML and all that.....
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é
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é
participants (2)
-
RC Compaan -
Steve Spicklemire