Re: Is this a violation of the EOF commandment?
Re: Is this a violation of the EOF commandment?
- Subject: Re: Is this a violation of the EOF commandment?
- From: Chuck Hill <email@hidden>
- Date: Thu, 12 Nov 2009 21:05:23 -0800
On Nov 12, 2009, at 7:12 PM, Ramsey Lee Gurley wrote:
On Nov 12, 2009, at 9:32 PM, Chuck Hill wrote:
On Nov 12, 2009, at 6:13 PM, Ramsey Lee Gurley wrote:
In this case though, he would be changing the value passed. It is
my understanding from the javadocs that this is what validateKey
methods are for, explicitly.
http://developer.apple.com/legacy/mac/library/documentation/InternetWeb/Reference/WO542Reference/com/webobjects/foundation/NSValidation.html
They even put 'coerce' in bold text. This certainly wouldn't be
the first time Apple's WO docs were wrong, but the way that
documentation reads, it seems coercing the value passed is one of
the primary reasons the method exists.
Perhaps we are not communicating. This is good and intended
public Object validateValueForCpt(Object value) {
if (value != null) return value.toString().toUpperCase();
return value
}
This is an abomination:
public Object validateValueForCpt(Object value) {
if (value != null) value = value.toString().toUpperCase();
setCpt(value);
return value
}
Oooooh, I see what you were saying. So then I assume that something
like
public Object validateRelatedEO(EnterpriseObject eo) {
if( something ) {
eo.setAttribute("Shriek");
}
}
or
public String validateColorAttribute(String color) {
if("orange".equals(color) ) {
setMakeAttribute("Mitsubishi");
}
}
are both equally bad.
Yes, that method should not change EO state, just return a coerced
value if appropriate.
I'll be honest and say I find this particular commandment
confusing. I can understand not wanting to change the value if it
is an EO (validateRelationship), but I'm not clear on how changing
the value passed would confuse EOF. The fact that validateKey is
being called on an attribute would indicate that EOF knows the
object has been changed. Is it perhaps the difference between being
inserted vs updated that causes the problem?
Not really sure what you are asking. The rule that (I think) you
are referring to is "Don't change the behavior of methods that EOF
uses."
I'm afraid I took that rule quite literally (^_^) Hence the alter
methods mentioned in a previous post. Thank you for these
examples. They are very clarifying.
You are welcome. I apologize for any confusion I may have caused you.
Chuck
This does not violate that rule:
public void setCpt(String value) {
if (value != null) value = value.toUpperCase();
super.setCpt(value);
}
Though it does come a little close to it. This does violate it:
public void setCpt(String value) {
if (value != null) {
value = value.toUpperCase();
super.setCpt(value);
}
}
And this does too
public String cpt() {
return cpt() != null ? cpt.toUpperCase() : null;
}
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