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: Ramsey Lee Gurley <email@hidden>
- Date: Thu, 12 Nov 2009 22:12:24 -0500
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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