Re: Vertical Inheritance qualifier based on to many relationship
On Aug 21, 2011, at 5:06 PM, Johan Henselmans wrote:
> Thanks for all the comments.
>
> It seems I have to rewrite the first part of my introductory WO-tutorial on
> creating a webobjects app, in which I did a vertical inheritance with
> subclasses of the contacts.
Well... maybe not. Just don't stop there, show how it is not the best design
decision and then show how using interfaces with roles is more flexible. Or at
least discuss it. Being too quick to apply inheritance is a common design
mistake, and not just with WO (I've made it. More than once. No, really!).
Dave
>
> On 21 aug. 2011, at 00:04, David Avendasora wrote:
>
>>
>> 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
>
Re: Vertical Inheritance qualifier based on to many relationship
Thanks for all the comments.
It seems I have to rewrite the first part of my introductory WO-tutorial on
creating a webobjects app, in which I did a vertical inheritance with
subclasses of the contacts.
On 21 aug. 2011, at 00:04, David Avendasora wrote:
>
> 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
Re: Vertical Inheritance qualifier based on to many relationship
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:
>
>>>
Re: Vertical Inheritance qualifier based on to many relationship
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".
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:
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
>>>
Re: Vertical Inheritance qualifier based on to many relationship
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: >>> >>> 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 > jo...@netsense.nl > > > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com > > This email sent to webobje...@avendasora.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Vertical Inheritance qualifier based on to many relationship
On 20/08/2011, at 6: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: > > I thought I used a Role pattern. situation: > base class is contact, others are inheritances all in the same table Sounds like you're confusing the role pattern with the decorator pattern. > 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? On each role's separate entity. That's the point of the role. It is not defined on the EO related to the role, but on the role's destination entity itself. Each contact can have one or more roles. You can't model that with inheritance but with toOne relationships. e.g., a director may or may not be a nice person, and so on. Lachlan Deck lachlan.d...@gmail.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Vertical Inheritance qualifier based on to many relationship
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.htmlI thought I used a Role pattern. situation:base class is contact, others are inheritances all in the same tablecontact - visitor -actor -director -nice personrole class - (defined via eo) contact<->role m:nI 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: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.nameWhat 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 DevelopmentPractical 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 Henselmansjo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Vertical Inheritance qualifier based on to many relationship
On 20/08/2011, at 9:26 AM, 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 Absolutely. Lachlan Deck lachlan.d...@gmail.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Vertical Inheritance qualifier based on to many relationship
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 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: > > 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Vertical Inheritance qualifier based on to many relationship
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. 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: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.nameWhat is the proper incantation to do this? Johan Henselmansjo...@netsense.nl ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
