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 18:32:03 -0800
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
}
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."
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
On Nov 12, 2009, at 6:35 PM, Chuck Hill wrote:
Yes, as long as you return the coerced value, not call set...
Making validate... change data is bad.
On Nov 12, 2009, at 3:32 PM, Travis Britt wrote:
validateValueForKey is safe for coercing user input tho right?
tb
On Nov 12, 2009, at 4:59 PM, David Avendasora wrote:
Nope. This is exactly where you should put this type of thing. If
you put this in the validation methods you'd be asking for trouble.
Dave
On Nov 12, 2009, at 4:49 PM, Ricardo J. Parada wrote:
public void setCpt(String value) {
if (value != null) value = value.toUpperCase();
super.setCpt(value);
}
P.S. I'm using eo-gap generation pattern. So this class extends
the _ class generated by the _WonderEntity.java template.
_______________________________________________
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
--
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