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.
>> 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.
Ramsey
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
