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.
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/webobjects-dev@lists.apple.com/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 (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40mac.com
>>
>> This email sent to rgur...@mac.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/rgurley%40mac.com
>
> This email sent to rgur...@mac.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
