On Aug 20, 2011, at 10:43 PM, Ken Anderson wrote: David,
When you say have a Relationship to the abstract Role class, I'm assuming you're recommending inheritance here. I do it the exact same way, just wanted to make sure it's not confusing to say "do abstract this" and also "get rid of inheritance".
Ah. Yes. Good point. I meant get rid of Inheritance on Contact. The roles themselves can make use of inheritance, or an even better way is for them to be individual Classes, but use interfaces to enforce what behaviors they each must have. Then you can have multiple interfaces associated with each role. For me, I have this type of structure in a few places. In one of them, the subclasses of Role use single table inheritance, since the subclasses all have similar data, but the methods are different. For another, I use horizontal, since the data structures vary significantly. Thankfully, there aren't thousands of objects, so performance is not a problem here.
Johan, you can always implement something in your Contact class like:
- (boolean) isActor { // check to see if the to-one (or to-many) role(s) relationship has an instance of the Actor role }
or something like this:
- (ActorRole *) actorRole { // find actor role in relationship or return null }
to see if the contact fits the bill for a particular situation or not. Personally, I always make the role relationship to-many, so that someone can have multiple roles (will ALWAYS happen IMHO).
Ken On Aug 20, 2011, at 6:33 AM, David Avendasora wrote: I've been there, Johan. Don't use inheritance. That's what is messing with you. An EO can't switch from being one Class to another. It completely er... um... screws with EOF.
Get rid of the inheritance. Just have a Contact class that has a relationship to the abstract Role class, and make all the the roles subclasses of Role. You can change a contacts behaviors by setting the role relationship to an instance of one of the subclasses on-the-fly, however you want. Each subclass of Role can implement the various behaviors in their own way.
The trick is that when you want a contact to behave as an actor, you set the role relationship to an instance of actor then call contact.role.assignUnderstudy(contact).
Wait, you say, it is completely invalid to take a role nicepersontoalwayinviteforfreetoanyshow and say contact.role.assgnUnderstudy(contact)! well, the NicePersonToAlwaysInviteForFreeToAnyShow class has an empty implementation of the assgnUnderstudy(contact) method, or one that throws an error that the UI catches to tell the user that they are a daft git for doing something stupid as trying to give a nicepersontoalwayinviteforfreetoanyshow an understudy. Shesh. Everyone knows they can only be assigned AS understudies.
That's the basics. Just get rid of Inheritance. Especially Vertical Inheritance (sorry Lachlan).
Dave On Aug 20, 2011, at 4:58 PM, Johan Henselmans wrote: On 20 aug. 2011, at 01:26, Chuck Hill wrote: On 2011-08-19, at 2:46 PM, Johan Henselmans wrote: My idea:
I have an entity contact, that gets vertically inherited into actor, employee, visitor, nicepersontoalwayinviteforfreetoanyshow, whatever, based on the role somebody/thing plays.
A contact can have different roles, which makes this contact playing actor, employee, visitor, nicepersontoalwayinviteforfreetoanyshow or whatever. So there is a m-n relation roles in a contact.
Where is Kieran? This is his favourite question. It sounds like you should be using the Role pattern and not inheritance. http://objectdiscovery.com/solutions/publications/roles/index.html
I thought I used a Role pattern. situation: base class is contact, others are inheritances all in the same table contact - visitor -actor -director -nice person
role class - (defined via eo)
contact<->role m:n
I would assume that figure 13 in the article would be the most desirable solution, as the role definition is dynamic (roles can be added)
but I do not get how in that situation the specific methods and data of a specific role would then be defined. Or perhaps I miss the point?
For instance, and actor can have a relationship to a specific show, a theatergroup, a paycheck, a visitor can have visited a specific performance, etc. Where would you define that kind of behavior?
I assumed that I should be able to create and get a visitor if I could describe in the EOModel qualifier something like roles.ROLE.name = 'visitor'
Something like this:
<PastedGraphic-3.png>
And I would create the relation to the role in the awakeFromInsertion phase of the Visitor.
Of course this is not working, (nothing ever works where I live) as I am getting
takeValueForKey(): attempt to assign value to unknown key: 'roles.ROLE.name'. This class does not have an instance variable of the name roles.ROLE.name
What is the proper incantation to do this?
I think that is not possible. The restricting qualifier has to be evaluated on that single entity only. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|