gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [GDL2] commit and few points


From: Manuel Guesdon
Subject: Re[2]: [GDL2] commit and few points
Date: Sun, 17 Apr 2005 15:29:15 +0200 (CEST)

Hi,

I'm back on this... :-)

On Tue, 01 Mar 2005 18:21:58 +0100 David Ayers <address@hidden> wrote:
 >| Manuel Guesdon wrote:
 >| 
 >| > On Sun, 13 Feb 2005 11:08:10 +0100 David Ayers <address@hidden> wrote:
 >| > 
 >| >  >| Manuel Guesdon wrote:
 >| >  >| 
 >| >  >| > I've temporary reverted David Ayers's changes in 
 >| >  >| > EOAttribute -adaptorValueByConvertingAttributeValue because we can 
 >| >  >| > have a NSString to to store in a NSNumber class attribute
 >| >  >| 
 >| >  >| Storing an NSString in something that's declared as NSNumber seems 
 >wrong 
 >| >  >| and I vagely rember testing it quite a bit.  Maybe we need some type 
 >of 
 >| >  >| formatter here though.  I'll go back and look at this, as I may be 
 >| >  >| missing something.
 >| > 
 >| > I think it's common as you often get user input (for date, number,...) as 
 >string
 >| > I haven't investigate deeper on this (lack of time) but we should find a 
 >way to 
 >| > well handle this. 
 >| > 
 >| 
 >| Hello Manuel,
 >| 
 >| Maybe we can look at this now.  If you have an attribute with 
 >| NSAdaptorNumberType, that means that the valueClass(Name) is some 
 >| NSNumber (sub)class.  So the EO(GenericRecord) is expected to return an 
 >| NSNumber for that attribute.  It seems that you have the situation that 
 >| somehow it actually contains an NSString.
 >| 
 >| I would expect a validation error during validateForSave: but maybe you 
 >| are not using and EOEditingContext here.
 >| 
 >| If this NSString stems from user input (I suspect a GSWTextField) then 
 >| it seems you may be missing a formatter which should convert the 
 >| NSString into an NSNumber /before/ the attribute value is set in the 
 >| EO(GenericRecord).  But I really think converting it in 
 >| -adaptorValueByConvertingAttributeValue: is wrong (and far too late for 
 >| many purposes).
 >| 
 >| Here is an example of how to add a formatter, but you probably already 
 >| know this:
 >| 
 >http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/Reference/DynamicElements/WOTextField.html


Yes, I know :-)

But doc:
http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Library/Frameworks/EOAccess.framework/ObjC_classic/Classes/EOAttribute.html#//apple_ref/occ/instm/EOAttribute/adaptorValueByConvertingAttributeValue:

says that - (id)adaptorValueByConvertingAttributeValue:(id)value
Ensures that value is either an NSString, NSNumber, NSData, or NSDate, ...

As far as I uderstand, it doesn't say that value should be of the same type 
than declareted in EOAttribute.

But I may be wrong. How do you undestand it ?


 >| PS: I haven't tested whether GSWeb actually does this conversion, but it 
 >| definitely should as it seems to be implemented in 
 >| -takeValuesFromRequest:inContext:

It does a conversion when there's a formatter.


Manuel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]