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 itai@c3works.com - Kermit the Frog "If you haven't got your health, you haven't got anything"
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 itai@c3works.com - Kermit the Frog
"If you haven't got your health, you haven't got anything"
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 itai@c3works.com - Kermit the Frog
"If you haven't got your health, you haven't got anything"
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 <itai@optusnet.com.au> 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 | >>> >>> ---------------------------------------------------------------------------------------- >>> 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> -- Itai Tavor "Je sautille, donc je suis." C3Works Itai> itai@c3works.com - Kermit the Frog Itai> "If you haven't got your health, you haven't got anything" Itai> _______________________________________________ Zope-Dev Itai> maillist - Zope-Dev@zope.org Itai> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross Itai> posts or HTML encoding! ** (Related lists - Itai> http://lists.zope.org/mailman/listinfo/zope-announce Itai> http://lists.zope.org/mailman/listinfo/zope )
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 <itai@optusnet.com.au> 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 | >>> >>> ---------------------------------------------------------------------------------------- >>> 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 itai@c3works.com - Kermit the Frog
"If you haven't got your health, you haven't got anything"
Hi Itai,
"Itai" == Itai Tavor <itai@optusnet.com.au> 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.)
Hi Steve, Steve Spicklemire wrote:
Hi Itai,
"Itai" == Itai Tavor <itai@optusnet.com.au> 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 problem is how to get the id of the new ToDo into the deliverable. If you didn't store todo_ids in Deliverable, instead calling ToDos.getToDosForDeliverable(), there would be no problem. Otherwise, you'd need a addToDoInterface in Deliverable, which will call ToDos.addToDo, then add the new ToDo id to todo_ids. Or, as a third option, you could pass a method to ToDos.addToDo, and get it to call this method and give it the new id. What do you think? Want to tackle this in the example? Itai -- Itai Tavor "Je sautille, donc je suis." C3Works itai@c3works.com - Kermit the Frog "If you haven't got your health, you haven't got anything"
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> itai@c3works.com - Kermit the Frog Itai> "If you haven't got your health, you haven't got anything"
participants (2)
-
Itai Tavor -
Steve Spicklemire