[Zope-dev] Re: ZPatterns, ObjectDomain, UML and all that.....
Itai Tavor
itai@optusnet.com.au
Fri, 15 Dec 2000 12:27:07 +1100
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"