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) > > > <figure-13.gif> > > 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 >> >> >> >> >> >> >> > > Johan Henselmans > [email protected] > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
