Phillip J. Eby wrote:
At 06:19 PM 11/29/00 +1100, Itai Tavor wrote:
Hi,
I'm trying to figure out the right way to implement a set of classes and roles in ZPatterns. I asked some questions about this a while ago, and then went away and did some learning, but I'm stuck again and I'm afraid I need to ask more questions.
I have two types of actors - Person (with properties name, phone, email, password) and Organization (with properties name, phone, fax, business_number).
I also have two participants - Customer and Reseller. Each participant can be either a Person or an Organization.
The participants can fill several roles, like OrderingEntities, BillableEntities, etc.
Starting from the bottom, I create a Specialist for each role, each one with two virtual Racks - customerRack and ResellerRack, so I can refer to an OrderingEntity without caring if it's a Reseller or Customer.
My problem is in implementing the Participant Specialists and storing Participant and Actor classes. Do I create Specialists for the Actors? It seems to me that since there is either one Person or one Organization per Customer, then the actor object should be created in the Customers Specialist. So Customers will have 3 Racks - defaultRack (using Customer object), personRack (using Person object) and organizationRack (using Organization object). Does this make sense?
I think what you want is to have an Actors specialist containing a personRack and organizationRack. That is, treat "Actor" as a role relative to either Customer or Reseller.
The reason I say, "I think", is because I'm really not clear on why you're doing certain things here to start with. See below.
If this is a good way to do it, how do I handle creating and accessing the Person and Organization objects? Do I call personRack.newItem(newCustomerId) in the script that creates the customer? Or do I somehow do it in a SkinScript in defaultRack? And how do I get to the Person data? With an attribute provider? Or in
Here's a red flag: why are you creating a person when you create a customer? If a person is something that you only make when you have a customer, then the actor-participant-transaction pattern isn't really valid, IMHO. For Actor-Participant-Transaction to make sense, you have to have Actors that exist seperate from the Participants. While it makes sense to be able to create an Actor at the same time, your model needs to also include a way to select an *existing* Actor as the Participant, otherwise you are not gaining anything from the A-P-T pattern and you might as well just have the Participant.
I think I have problems understanding the whole A-P-T pattern. Maybe someone can help clear it up for me... An Actor is a Person or an Organization. A Participant can be (in my application) a Customer, Customer Contact, Reseller, ResellerContact, or Employee. Participants have different roles - for example, all Participants can place orders on behalf of customers, and they take on the OrderingEntity role. Orders are always paid for by Customers in their role as BillableEntities. Now, OrderingEntities and BillableEntities are roles that actualize the object connections between the Participants and the Transaction objects (in the above examples, the Transaction object would be Order), right? They are not new Participants. So in this application, while Participants can fill multiple roles, each Actor can only be a single Participant. A Person participating as a CustomerContact is (in the real world) employed by the Customer, so in the application she won't participate as anything else. So the A-P pattern seems to serve the purpose of reusing common properties and methods, rather than allowing for n-1 relationship between Actors and Participants. This seems to me to suggest that the application should have a Person class but that the Person will get created when a new Participant is created, and that a 'select existing Actor as Participant' interface, as Phillip suggests above, is not necessary. Am I right, or do I persist in misunderstanding A-P-T? A related problem I've been struggling with is how to allow a Reseller to buy product for itself/herself. Normally orders are placed for Customers only. Would it make more sense to create a role for entities that receive orders (implemented as a Specialist with virtual Racks for Customers and Resellers), or to complicate the A-P pattern by allowing a single Actor to be both a Reseller and a Customer? The new role path seems to make more sense to me, but I've been known to be wrong before :).
Here's a pattern for mapping A-P-T interactions onto ZPatterns, however... If you are doing A-P-T, make sure you use a Specialist for access to the Actors. For example, in some applications Ty and I write, "acl_users" is designated as the Specialist for actors if all actors in the system have to be able to use the application. The user interface and implementation for creating and/or selecting actors to fill a participant role is placed in the actors' specialist - acl_users in our case, or perhaps a specialist called "Actors" in yours. (But I'd recommend you use a domain-specific name, if possible.) So you would not be worrying about whether to create a person or organization or what fields they need or anything else in the specialist for your "participant" objects. Indeed, you wouldn't be worrying about whether a new one was being created, or an old one selected, if you delegate that aspect of the UI to the actors' Specialist.
I like the idea of using acl_users as the actors Specialist, it's much simpler than what I intended to do - have virtual Racks in acl_users that access users in all the different Participant Specialists. But doing it this way creates another problem for me - your acl_users authenticates Actors, not Participants. But in many cases the application needs to know the Participant* , and that requires that the Actor know its Participant. But knowing the Participant requires knowing the *type* of Participant - which is very ugly. How would you work this out? * For example, an employee of a reseller company logs in and places an order for a customer. The Participant is a ResellerContact, and a commission from the order has to be credited to the Reseller. 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"