On Nov 13, 2009, at 12:05 AM, Chuck Hill wrote: > 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
Oh, no apologies necessary. Thank you again! (^_^)
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
>>
>
> --
> 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
>
>
>
>
>
>
>
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
