Re: Owns destination implies mandatory?
Re: Owns destination implies mandatory?
- Subject: Re: Owns destination implies mandatory?
- From: Chuck Hill <email@hidden>
- Date: Thu, 12 Nov 2009 10:58:15 -0800
On Nov 11, 2009, at 4:58 PM, Ramsey Lee Gurley wrote:
Whoops, I just noticed you started this thread (^_^) I was wanting
to say one other thing in regards to this anyway.
I'm not sure this is the 'advised' way to do things, so we might
want to wait for Chuck's approval on this... (^_^) However, the
strategy I've settled on recently is to use a cover method for
anything that might cause side effects beyond setting a value.
For the example below, I see no harm in doing that directly in the
setColor method.
Chuck
Let's say I have a car object. It has a make and a color. If it is
orange, it can't be a Ford, because there are no orange Fords... so
instead of binding directly to color, I bind to a getter/setter that
not only set the color, but also do the checks necessary to ensure
the car is not a ford. something like
public Color alterColor() { return color(); }
public void setAlterColor(Color color) {
Color oldColor = color();
//Run regular validation first if desired
color = validateTakeValueForKeyPath(color);
//Alter the EO to conform to whatever business rules you have
if(Color.ORANGE.equals(color) && Make.FORD.equals(make())) {
setMake(null);
}
//etc...
}
Then when binding the form element, instead of binding car.color, I
bind to car.alterColor instead.
I _was_ doing this sort of thing in my validateKey methods until I
learned that updating values in validateKey goes against the EOF
commandments. So I've mended my ways and this seems to be working
pretty well so far.
Ramsey
Oh, and the push changes thing appears to be controlled by a
property. It appears that if you want to turn it on you would put
er.extensions.ERXValidationShouldPushChangesToObject=true
In your properties file.
On Nov 11, 2009, at 7:28 PM, Ramsey Lee Gurley wrote:
Hi Ricardo,
I think Anjo's reply was in regards to postponed validation, not
your issue with ERDEditOwnedRelationship. I'm honestly not sure
why you're getting validation errors with that component, because
I've never actually used it. Try searching the list, I've heard
David LeBer mention it a time or two.
That said, have you tried an edit fault component instead?
http://developer.apple.com/legacy/mac/library/documentation/InternetWeb/Reference/WO542Reference/com/webobjects/directtoweb/D2WEditToOneFault.html
That will take you to an edit relationship page where I can attest
that mandatory relationships for newly created EOs works just fine.
As for making the owns relationship mandatory vs. optional, there
was some discussion regarding this back in March. You might find
the discussion interesting.
http://www.mail-archive.com/email@hidden/msg27230.html
Ramsey
On Nov 11, 2009, at 5:37 PM, Riccardo De Menna wrote:
Hi,
Does the "owns destination" concept imply that the relationship is
also "mandatory" for the owned object?
If yes, is it enforced somehow if I don't turn on the mandatory
flag in the model?
I'm asking since I'm having issues with ERDEditOwnedRelationship
(I posted a message on the wonder list for that but didn't find
someone to discuss it)...
I have something like the following:
Person >> Membership << Club
A person HAS to have at least one membership to a club. I'd go with:
Person owns membership
Club owns membership
Person.memberships is mandatory
Membership.person is mandatory
But this is conflicting with ERDEditOwnedRelationship that wants
to postpone relationship linking to the NextDelegate phase. This
clashes with validation.
So my question is... if I drop the two mandatory concepts does the
ownership still imply they are needed and will anyone enforce it?
rdm
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
--
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