[Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....

[Itai Tavor]

>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"