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: Fri, 13 Nov 2009 07:21:06 -0500
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
>
>
>
>
>
>
>
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