Re: [Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
Hi Itai, Good idea! I'll try to add this to the example. thanks! -steve Itai> P.S. I've been struggling with a problem that might get Itai> cleared up if you added it to the example: Itai> Say you want to allow a user to add a ToDo from the Itai> Deliverable screen (in addition to the existing menu for Itai> selecting existing ToDos). You could either place a 'create Itai> ToDo' form right there, using a UI snippet from ToDos, or Itai> link to ToDos.addToDoForm. The problem is how to get the id Itai> of the new ToDo into the deliverable. If you didn't store Itai> todo_ids in Deliverable, instead calling Itai> ToDos.getToDosForDeliverable(), there would be no Itai> problem. Otherwise, you'd need a addToDoInterface in Itai> Deliverable, which will call ToDos.addToDo, then add the new Itai> ToDo id to todo_ids. Or, as a third option, you could pass a Itai> method to ToDos.addToDo, and get it to call this method and Itai> give it the new id. Itai> What do you think? Want to tackle this in the example? Itai> Itai -- Itai Tavor "Je sautille, donc je suis." C3Works Itai> [EMAIL PROTECTED] - Kermit the Frog Itai> "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 )
Re: [Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
Hi Steve, Steve Spicklemire wrote: >Hi Itai, > >> "Itai" == Itai Tavor <[EMAIL PROTECTED]> writes: > > Itai> I'm already using globally unique ids, but still, doesn't > Itai> using the same id for the Participant and the Actor make > Itai> these objects too tightly coupled? Seems to me that Actors > Itai> should provide an interface for finding actors to the rest > Itai> of the application; other objects should not make > Itai> assumptions about the internal storage of Actors, and > Itai> particularly what ids they use. No? > >Well... there are two aspects here: 1) Who knows about how >various Participants and Actors are managed and 2) How are they actually >managed. Tight coupling is only about "1". It seems to me that "2" is >up to you as the developer to decide based on the particular >situation. > >I'm sure that ZPatterns Zen is like most things... you learn by >getting your fingers burnt ;-). However it seems to me that it >should be OK for an Xs Specialist to implement > >getXforY( y_id ) > >or > >getXsforY( y_id ) > >(if there is more than one x for a single y. > >If you have an XOR relationship, with several potential Specialists >I think you could either: > >(A) iterate through the list of possible Specialists and ask each to >getXforY until you get a hit... > >or > >(B) have a 'clearing house' Participants specialist, with a Rack for >each of the >Participant types and let it iterate through the racks and return >an object of the right type based on which one is a 'hit'. (Specialists >of course do this automatically!) > >The advantage of (A) is, one less Specialist. The disadvantage is that >the Actor Specialist needs to 'know' about the list of Participant Specialists >itself. > >The advantage of (B) is that the clearing house Specialist keeps track >of all the different Participants types... and the iteration is 'automatic'. > >However... I think that either of these is 'OK' as far as coupling is >concerned. In both cases the information about the different types >of Participant is kept in a single centralized place [(A) in the >Actors Specialist] and [(B) in the clearing house Specialist]. *If* >you had some *other* Specialist that also needed to iterate through the >various types of Participants... *then* B would be a clear advantage, >and probably worth the added complexity. I use (B) when some participants need to take on a certain role, like 'ordering entities', 'billable entities', etc. In this case, each role might be filled by a different group of participants, so a new Specialist is necessary. I implemented this for my Actors like you suggested, and it works nicely and doesn't seem overly complicated. In other XOR cases, I would favor (A). I think (B) in these cases would be an overkill. One thing about implementing (A) - it can be done in two ways: - Store participant_id in Actor. Actor calls ParticipantSpecialist.getParticipant(self.participant_id) - Store actor_id in the participants. Actor calls ParticipantSpecialsit.getParticipantForActor(self.id) Or, you'd probably want to do both - store Actor.my_participant_id and Participant.my_actor_id. But in this case, you don't need getParticipantForActor, you just use getParticipant(self.my_participant_id). Does this make sense? >(P.S. it was refreshing to hear pje mention that he and Ty had to "bite the >bullet" and add new classes/Specialists on a project and only *after* that >it got much simpler, clearly implying that the original design was less >than perfect. It seems to us newbies sometimes that they possess >the Deific characteristic of near (object oriented) infallibility whereby >they produce clean, elegant, yet simple object oriented designs with the >same graceful ease with which they might compose a grocery list, while we >mortals struggle for hours and days to come up with something that they might >discard after a moment's thought. Anyway in the end we'll all learn the >most by hard experience, if only she were a more forgiving Mistress!) Being able to get it right the second time is still close enough to infallible for me :-) >(P.P.S. I still really like your idea of codifying some of these >ZPatterns techniques into a sort of gallery of ZPatterns Implementations. >I'm working already on incorporating some of these into the ToDo example.) I'd like to see what you manage to fit into the example. I think that once you get one implementation from the gallery added, and we can see that it's simple and works well in this application, we can consider it our 'recommended implementation of the moment'. P.S. I've been struggling with a problem that might get cleared up if you added it to the example: Say you want to allow a user to add a ToDo from the Deliverable screen (in addition to the existing menu for selecting existing ToDos). You could either place a 'create ToDo' form right there, using a UI snippet from ToDos, or link to ToDos.addToDoForm. The prob
Re: [Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
Hi Itai, > "Itai" == Itai Tavor <[EMAIL PROTECTED]> writes: Itai> I'm already using globally unique ids, but still, doesn't Itai> using the same id for the Participant and the Actor make Itai> these objects too tightly coupled? Seems to me that Actors Itai> should provide an interface for finding actors to the rest Itai> of the application; other objects should not make Itai> assumptions about the internal storage of Actors, and Itai> particularly what ids they use. No? Well... there are two aspects here: 1) Who knows about how various Participants and Actors are managed and 2) How are they actually managed. Tight coupling is only about "1". It seems to me that "2" is up to you as the developer to decide based on the particular situation. I'm sure that ZPatterns Zen is like most things... you learn by getting your fingers burnt ;-). However it seems to me that it should be OK for an Xs Specialist to implement getXforY( y_id ) or getXsforY( y_id ) (if there is more than one x for a single y. If you have an XOR relationship, with several potential Specialists I think you could either: (A) iterate through the list of possible Specialists and ask each to getXforY until you get a hit... or (B) have a 'clearing house' Participants specialist, with a Rack for each of the Participant types and let it iterate through the racks and return an object of the right type based on which one is a 'hit'. (Specialists of course do this automatically!) The advantage of (A) is, one less Specialist. The disadvantage is that the Actor Specialist needs to 'know' about the list of Participant Specialists itself. The advantage of (B) is that the clearing house Specialist keeps track of all the different Participants types... and the iteration is 'automatic'. However... I think that either of these is 'OK' as far as coupling is concerned. In both cases the information about the different types of Participant is kept in a single centralized place [(A) in the Actors Specialist] and [(B) in the clearing house Specialist]. *If* you had some *other* Specialist that also needed to iterate through the various types of Participants... *then* B would be a clear advantage, and probably worth the added complexity. Anyway.. just my random thoughts. -steve (P.S. it was refreshing to hear pje mention that he and Ty had to "bite the bullet" and add new classes/Specialists on a project and only *after* that it got much simpler, clearly implying that the original design was less than perfect. It seems to us newbies sometimes that they possess the Deific characteristic of near (object oriented) infallibility whereby they produce clean, elegant, yet simple object oriented designs with the same graceful ease with which they might compose a grocery list, while we mortals struggle for hours and days to come up with something that they might discard after a moment's thought. Anyway in the end we'll all learn the most by hard experience, if only she were a more forgiving Mistress!) (P.P.S. I still really like your idea of codifying some of these ZPatterns techniques into a sort of gallery of ZPatterns Implementations. I'm working already on incorporating some of these into the ToDo example.) ___ 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] Re: ZPatterns, ObjectDomain, UML and all that.....
>Hi Itai, > >Ok.. I'm working an DumbZPatternsExample V3.0 so this is exactly >the sort of conversation that needs to take place for me. ;-) Godd to hear that (both that the discussion is helping you, and that you're working on a new dumb example :-) ) >It seems to me that when you want a Reseller, or a Customer you >certainly want to go to the Resellers or Customers Specialist and ask >for the Participant. So.. since there is never more than one Actor for >each Participant, I think I'd keep the information about the actor_id >in the Participant. I might even suggest that you could use the actor_id >as the participant_id, depending on how these id's are implemented. >(it seems that it would be particularly nice if the ids are known to >be globally unique that you could use this fact to help identifying >relationships...) I'm already using globally unique ids, but still, doesn't using the same id for the Participant and the Actor make these objects too tightly coupled? Seems to me that Actors should provide an interface for finding actors to the rest of the application; other objects should not make assumptions about the internal storage of Actors, and particularly what ids they use. No? >Now.. you seem to be asking how to run it the other way around. >How do we get the correct Participant from the Actors specialist? >Hmm... I'm not sure what the scenario would be that would require >this, but it seems to me that it's a reasonable enough possibility. Well, Actors store user info such as login_name, password, and roles. So it's natural (I think) for acl_users to authenticate against Actors, rather than ask each Participant Specialist to search all the Actors associated with its Participants. So AUTHENTICATED_USER is an Actor. But the application needs to know the Participant - for example, if a Customer is placing an order, she will be asked to identify her Reseller. But if a Reseller is placing the order, the application already knows the Reseller, but it needs to ask for a Customer. So, from the Actor, I need to know the Participant type, id, name, etc. Unless, of course, I'm making things too complicated again, and it really is better to authenticate Participants rather than Actors... >How about a little search... : > >PythonScript: getParticipantFor( self, participantSpecialistList ) > > while Participants in participantSpecialistList: > theParticipant = Participants.getParticipantForActor( self.actor_id ) > if theParticipant is not None: >break > > return theParticipant > >It's up to the 'Participants' Specialists to implement getParticipantForActor >based on the actor_id. (if actor_id is the same as reseller_id then it's >just getItem!) Now... to make this slick, add an attribute handler for >your actor that does this automagically when you ask for 'participant'. > >I think something like: > >WITH self.getParticipantFor( [Resellers, Customers] ) COMPUTE >myParticipant = RESULT or NOT_FOUND > >should do it. In code you just say: > >resellerName = self.myParticipant.name > >or somthing like that. > >Of course.. I've not tried this. But it *seems* like it should work. ;-) I imagine it would... and it looks pretty good. The question is, and that brings us back to the object connections table, whether this is really the way you would want to do it. Itai >-steve > >> "Itai" == Itai Tavor <[EMAIL PROTECTED]> writes: > > Itai> There might be many ways to implement each connection, but I > Itai> think that there will always be one or two ways that would > Itai> be simplest and most robust... so this would not only save > Itai> you the trouble of figuring it out alone every time, but > Itai> would also prevent you from getting stuck down the road. > > Itai> The problem is that we have at best guesses, and at worst > Itai> empty table cells in the guide. I'm still struggling with > Itai> many of these... The worst one seems to be XOR type > Itai> connections, where a Specialist implementing a role is not > Itai> involved. Example: > > Itai> Actor: Person. > > Itai> Participants: Customer, Reseller > > Itai> Object connections: (Customer) 1---[XOR A] 1 (Actor) > Itai> [XOR A] 1---1 (Reseller) > > Itai> acl_users Login Manager authenticates users using Actor > Itai> objects (by connecting the the Actors Specialist). The > Itai> application needs to identify the Participant. > > Itai> If you add participant_id to Actor, you still don't know > Itai> which Participant Specialist to load the Participant > Itai> from. You don't want to add participant_type to Actor (at > Itai> least, I don't think you do - it seems real ugly). So, what > Itai> do you do? Do you place the Customers and Resellers > Itai> Specialists inside a Participants Specialist? We'll have to > Itai> call it MegaSpecialist :-). Bad idea - other parts of the >
Re: [Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
Hi Itai, Ok.. I'm working an DumbZPatternsExample V3.0 so this is exactly the sort of conversation that needs to take place for me. ;-) It seems to me that when you want a Reseller, or a Customer you certainly want to go to the Resellers or Customers Specialist and ask for the Participant. So.. since there is never more than one Actor for each Participant, I think I'd keep the information about the actor_id in the Participant. I might even suggest that you could use the actor_id as the participant_id, depending on how these id's are implemented. (it seems that it would be particularly nice if the ids are known to be globally unique that you could use this fact to help identifying relationships...) Now.. you seem to be asking how to run it the other way around. How do we get the correct Participant from the Actors specialist? Hmm... I'm not sure what the scenario would be that would require this, but it seems to me that it's a reasonable enough possibility. How about a little search... : PythonScript: getParticipantFor( self, participantSpecialistList ) while Participants in participantSpecialistList: theParticipant = Participants.getParticipantForActor( self.actor_id ) if theParticipant is not None: break return theParticipant It's up to the 'Participants' Specialists to implement getParticipantForActor based on the actor_id. (if actor_id is the same as reseller_id then it's just getItem!) Now... to make this slick, add an attribute handler for your actor that does this automagically when you ask for 'participant'. I think something like: WITH self.getParticipantFor( [Resellers, Customers] ) COMPUTE myParticipant = RESULT or NOT_FOUND should do it. In code you just say: resellerName = self.myParticipant.name or somthing like that. Of course.. I've not tried this. But it *seems* like it should work. ;-) -steve > "Itai" == Itai Tavor <[EMAIL PROTECTED]> writes: Itai> There might be many ways to implement each connection, but I Itai> think that there will always be one or two ways that would Itai> be simplest and most robust... so this would not only save Itai> you the trouble of figuring it out alone every time, but Itai> would also prevent you from getting stuck down the road. Itai> The problem is that we have at best guesses, and at worst Itai> empty table cells in the guide. I'm still struggling with Itai> many of these... The worst one seems to be XOR type Itai> connections, where a Specialist implementing a role is not Itai> involved. Example: Itai> Actor: Person. Itai> Participants: Customer, Reseller Itai> Object connections: (Customer) 1---[XOR A] 1 (Actor) Itai> [XOR A] 1---1 (Reseller) Itai> acl_users Login Manager authenticates users using Actor Itai> objects (by connecting the the Actors Specialist). The Itai> application needs to identify the Participant. Itai> If you add participant_id to Actor, you still don't know Itai> which Participant Specialist to load the Participant Itai> from. You don't want to add participant_type to Actor (at Itai> least, I don't think you do - it seems real ugly). So, what Itai> do you do? Do you place the Customers and Resellers Itai> Specialists inside a Participants Specialist? We'll have to Itai> call it MegaSpecialist :-). Bad idea - other parts of the Itai> application have to access Resellers specifically, so Itai> Resellers should not be hidden inside the Itai> MegaSpecialist. So, do you create a Participants Specialist Itai> with virtual Racks for Customers and Resellers? What, Itai> another Specialist just to link Actors to Participants? Will Itai> this never end :-(? Itai> See, I'm stuck. Please please please could someone who do Itai> not identify themselves as ZPatterns novices find the time Itai> to add to this guide? Itai> Steve Spicklemire wrote: >> I think this is a brilliant idea! I'm sure there are sixteen >> ways to implement each of these... but having one concrete way >> would be a big help to a novice >> >> -steve >> >>> >>> >>> 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 | >>> >>> -
[Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
There might be many ways to implement each connection, but I think that there will always be one or two ways that would be simplest and most robust... so this would not only save you the trouble of figuring it out alone every time, but would also prevent you from getting stuck down the road. The problem is that we have at best guesses, and at worst empty table cells in the guide. I'm still struggling with many of these... The worst one seems to be XOR type connections, where a Specialist implementing a role is not involved. Example: Actor: Person. Participants: Customer, Reseller Object connections: (Customer) 1---[XOR A] 1 (Actor) [XOR A] 1---1 (Reseller) acl_users Login Manager authenticates users using Actor objects (by connecting the the Actors Specialist). The application needs to identify the Participant. If you add participant_id to Actor, you still don't know which Participant Specialist to load the Participant from. You don't want to add participant_type to Actor (at least, I don't think you do - it seems real ugly). So, what do you do? Do you place the Customers and Resellers Specialists inside a Participants Specialist? We'll have to call it MegaSpecialist :-). Bad idea - other parts of the application have to access Resellers specifically, so Resellers should not be hidden inside the MegaSpecialist. So, do you create a Participants Specialist with virtual Racks for Customers and Resellers? What, another Specialist just to link Actors to Participants? Will this never end :-(? See, I'm stuck. Please please please could someone who do not identify themselves as ZPatterns novices find the time to add to this guide? Steve Spicklemire wrote: > I think this is a brilliant idea! I'm sure there are sixteen >ways to implement each of these... but having one concrete way would >be a big help to a novice > >-steve > >> >> >> 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] Re: ZPatterns, ObjectDomain, UML and all that.....
Itai, I think this is a brilliant idea! I'm sure there are sixteen ways to implement each of these... but having one concrete way would be a big help to a novice -steve > > >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] 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] 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.....
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 )
[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 )
