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

[Steve Spicklemire]

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 )