[Zope-dev] 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é ___ 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] debugging authentication problems
On Mon, 04 Dec 2000 09:38:10 +, Chris Withers [EMAIL PROTECTED] wrote: Toby Dickenson wrote: Im have trouble tracking down why one specific method is needing authentication. Can anyone suggest any tips or tools? Toby Dickenson [EMAIL PROTECTED] Shane's ZDebug tool can help, but where people have helpfully raised Unauthorized as a string exception, it doesn't seem to kick in. If anyone's got any other tips, I'd love to hear them too :-) Now Ive found the problem, I dont think anything less than pdb would have helped. Thanks for the tips, Toby Dickenson [EMAIL PROTECTED] ___ 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] Implementing [XOR A] 1 object connections in ZPatterns
Hi Itai, "Itai" == Itai Tavor [EMAIL PROTECTED] writes: ... Itai The 2nd way seems to go better with OO principles - all Itai handling of photos is delegated to the Photos Specialist and Itai the Product doesn't care if the photo exists or not, or Itai where it comes from. But it also increases complexity in Itai Photos, because I need to implement an efficient way to Itai retrieve photos (with a Catalog, or SQL searches), and Itai because it introduces the photo_key. Storing photo_id in Itai Product eliminates these complexities, but it moves some of Itai the responsibility for managing photos into Product. Hmmm.. it seems to me that it makes more sense for the Product to know the id of the Photo that *it* needs to display itself than for the Photo to have to know that it belongs to a particular Product. Also.. I can imagine that the Photo class might be useful for lots of other things besides Products, and how would you teach it what type of object it belongs to? Just my $0.02. ;-) -steve ___ 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] time-travel how to?
Thanks for the tip. Yes, the HistoricalRevisions subsystem looks interesting. Im not sure it solves my problem though, in that the revisions seem to be for a single given object, rather than for a given subtree or site. They certainly dont seem to apply to folderish objects. For my application, making read-only restrictions on time-travel is perfectly acceptable, so I dont believe that paradoxes are of concern. Anyone have any suggestions about where to start with this? -Original Message- From: Shane Hathaway [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 11:05 AM To: [EMAIL PROTECTED] Subject: Re: [Zope-dev] time-travel how to? Damien Morton wrote: How do you access the fabled time travel features of Zope? Reading through the source I see that you can open a database in read only mode and specify the point in time that that view is for. Would it be possible to mount the same data.fs multiple times in read-only mode, each mounting with a different temporal view? Is there some other mechanism by which the time-travel feature can be accessed? Ideally it would be possible to create a temporal view of the database much like one would create a version, but that the view would be enabled by traversing through that view in the URL. See the history tab of DTML methods. For example, http://foo.com/nov3/x/y/z would be a view of the database at nov3, where the actual time and date of the view would be specified in the nov3 object. That would be spiffy! It would be fun to visit: http://mysite.com/HistoricalRevisions/2000Jan01/manage It's also very doable. Of course, time travel restrictions would have to be imposed. (Zope will produce a "temporal paradox" exception if you do the right thing. It's something of an easter egg IMHO.) Shane ___ 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 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 )
[Zope-dev] Zope 2.3 plan updated...
Hi all - We're gearing up for getting a new feature release out so for those interested I've updated the Zope 2.3 plan at: http://dev.zope.org/Resources/zope_230_plan.html The main changes from the prior version are that it is much more detailed, some items have been added and the item for updating ZDOM to DOM level 2 has been dropped (until there is a clearer justification for it). I hope to make an alpha 1 release on Monday the 11th with the new Python Scripts and fixed user bootstrapping, among other things (see the plan for details). Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ 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] Re: ZPatterns, ObjectDomain, UML and all that.....
Steve Spicklemire wrote: "RC" == RC Compaan [EMAIL PROTECTED] 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 ... g... ;-) It is the software that comes with the book, and it is Win only. I started using it but switched to ConceptDraw because I got tired of turning my chair around to face the Windows machine every time I wanted to look at my object model. Like Roche said, you don't need code generation, so all you need is to be able to place classes and connect them. Playground is nice in that it actually knows about classes and lets you view class lists, create connections from the list and so on. ConceptDraw is just a drawing program so you won't have class lists, and the libraries aren't complete, but on the other hand, it works well on a Mac and, unlike Playground, it lets you do Coad, UML, Use Cases, activity diagrams, sequence diagrams, component diagrams, collaboration diagrams... Itai -- 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] 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] RE: ZPatterns, ObjectDomain, UML and all that.....
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 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. 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 = Bs.getItem(b_id) 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 = As.getItem(a_id) 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 -- 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] 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] ZPatterns scalability...
Just to get more opinions... we have a service coming up where we'd like to use a Zope/Zpatters solution. Its a feedback tool, with the potential of up to 50,000 entries. These would be stored in a Specialist/Rack/DataSkin combo, stored in a standard zodb/filestorage system. Using a ZCatalog for listings and the Specialist.getItem() for individual record retrieval. Any thoughts on scalability issues. Thanks in advance for any insights. -- John Eikenberry [[EMAIL PROTECTED] - http://zhar.net] __ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin ___ 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] Re: ZPatterns, ObjectDomain, UML and all that.....
Thanks Roche! "RC" == RC Compaan [EMAIL PROTECTED] 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 ... g... ;-) 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é ___ 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 )
