[Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....
I've been using DOmain Modeling Environment(DOME) for OOA/OOD recently. I use it because like ZOPE it has many features most important one being free. It has support for Coad notation and a list of others. IMHO it could be the default ZPatterns design tool of choice because you can extend it to include the ZPatterns concepts and it supports windows, and the PowerMac using VisualWorks. Has anybody out there had any experience with DOME ? DOME (the DOmain Modeling Environment) is a meta-CASE system suitable for building object oriented software models (Coad-Yourdon OOA and UML, for example), and more importantly, for building original types of models. It includes a graphical front-end, and a powerful back-end language for generating code, analyses and documentation. It is fully functional, tested, documented, and it is free, distributed under GNU General Public licenses. Download http://www.htc.honeywell.com/dome/download.htm">here There is a Linux version and Smalltalk Source Code for VisualWorks 5i ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....
At 09:44 PM 12/5/00 +0200, Roch'e Compaan wrote: >> If you want to store one DataSkin inside another, where either one of them >> is stored in a Rack, you will have to create appropriate SkinScript or >> custom attribute providers to do so. > >But what if I always store dataskins in there own racks but simply assign an attribute of one >Dataskin to the instance of another Dataskin? I simply want to be able to say >Customer.Address.Street... > As implied above, you cannot, unless you do so with an appropriate provider. Just like ZODB-stored objects, ZPatterns objects cannot function if you break the rules that govern their behavior. (E.g. if you change a mutable value of a ZODB object, it has no way to know it should be saved to the database.) This is a "by design" limitation of ZPatterns. Also, it's not that bad of a limitation. You can easily work around it with SkinScript or an attribute provider, and more commonly, this is done by delegation to another specialist. Specifically, rather than breaking encapsulation by having application code write to an attribute directly, you use a method which delegates to the foreign specialist, asking it to link or create an associated object. You can then still use SkinScript to retrieve your "Address" attribute, again by delegation to the other Specialist. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....
> If you want to store one DataSkin inside another, where either one of them > is stored in a Rack, you will have to create appropriate SkinScript or > custom attribute providers to do so. But what if I always store dataskins in there own racks but simply assign an attribute of one Dataskin to the instance of another Dataskin? I simply want to be able to say Customer.Address.Street... > > > >PS: I checked Rack.py: > > > >CreateItem call _RawItem and in _RawItem the Rack for that instance is set: > > item._setRack(Self) # Connect to Rack > > > >I might be wrong but after a quick look at the attributehandling code in > >Dataskins.py suggests that the Dataskin does not know who its datamanager > >is. > > Yes, it does. _setRack() is called whenever a DataSkin is retrieved from a I meant to say "it DOES know" - but I do NOT :) Roché ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....
At 03:18 PM 12/5/00 +0200, RC Compaan wrote: > >> 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. > >If this is the case then my current implementation will have to change quite >dramatically :( I don't quite understand why Dataskins are implemented in >this way - this obstructs natural object oriented programming? I would have >thought that the datamanager is set when the a Dataskin is created. Keep in mind that DataSkins are intended to be able to be *non* persistent objects, stored in a relational database, for example. And the Rack is not stored in the RDBMS. There is no conflict with O-O programming, however. In fact, this is a high-encapsulation situation. Specifically, you don't mess with the innards of a DataSkin if you're just a client of it. :) If you want to store one DataSkin inside another, where either one of them is stored in a Rack, you will have to create appropriate SkinScript or custom attribute providers to do so. >PS: I checked Rack.py: > >CreateItem call _RawItem and in _RawItem the Rack for that instance is set: > item._setRack(Self) # Connect to Rack > >I might be wrong but after a quick look at the attributehandling code in >Dataskins.py suggests that the Dataskin does not know who its datamanager >is. Yes, it does. _setRack() is called whenever a DataSkin is retrieved from a Rack. Or, if a DataSkin is stored outside a Rack, its __of__() method searches the acquisition hierarchy for a Customizer or Folder with Customizer Support in order to acquire a data manager. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] FW: ZPatterns, ObjectDomain, UML and all that.....
(forgot to cc this to zope-dev) -Original Message- From: RC Compaan [mailto:[EMAIL PROTECTED]] Sent: 05 December 2000 03:17 To: [EMAIL PROTECTED] Subject: RE: ZPatterns, ObjectDomain, UML and all that. > 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: Well so far it seems to work fine... I do however receive a KeyError with one of my Dataskins but this is isolated to one particular Dataskin. I did not inspect the innards of ZPatterns that well, I must say, so this issue still remains unresolved to me as well. > 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. If this is the case then my current implementation will have to change quite dramatically :( I don't quite understand why Dataskins are implemented in this way - this obstructs natural object oriented programming? I would have thought that the datamanager is set when the a Dataskin is created. > 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? They are all external methods - I do most of my development with ZClasses and Python Methods make life a lot easier. Roché PS: I checked Rack.py: CreateItem call _RawItem and in _RawItem the Rack for that instance is set: item._setRack(Self) # Connect to Rack I might be wrong but after a quick look at the attributehandling code in Dataskins.py suggests that the Dataskin does not know who its datamanager is. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
