myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <mat...@apache.org>
Subject Re: submittedValue vs. Converter.getAsObject
Date Wed, 08 Sep 2010 09:25:39 GMT
eh, miss read. does not lack the NULL handling

On Wed, Sep 8, 2010 at 11:22 AM, Matthias Wessendorf <matzew@apache.org> wrote:
> Hello,
>
> in Trinidad we don't cast to String:
>
> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/EditableValueRenderer.java?view=annotate
>
> (see line 133->135)
>
> This is because of supporting the "oracle adf numbers", like:
> http://download.oracle.com/docs/cd/E12839_01/apirefs.1111/e10655/index.html?oracle/jbo/domain/Number.html
>
> The fix is simple: call toString() instead of doing the cast.
>
> However, I think your patch misses the case of tolerating NULL (new w/ jsf2)
>
> -Matthias
>
> On Tue, Sep 7, 2010 at 11:05 PM, Martin Koci
> <martin.kocicak.koci@gmail.com> wrote:
>> Hi,
>>
>> maybe this is a stupid question but:
>>
>> >From UIInput javadoc:
>>
>> ... decoded value of this component, usually but >>>not necessarily a
>> String<<<, must be stored - but not yet converted - using
>> setSubmittedValue() ....
>>
>>
>> from UIInput.getConvertedValue:
>>
>> ... and the submitted value is a >>>String<<<, locate a Converter
as
>> follows
>>
>> Question: why is Converter tied  only to String? Whole specification
>> speaks about submitted value as of "raw representation of value from
>> client" but not necessarily String. And 3.3 Conversion Model: "This
>> section describes the facilities provided by JavaServer Faces to support
>> type conversion between server-side Java objects and their (typically
>> String-based) representation in presentation markup."
>> But Converter.getAsObject expects only String as this "raw
>> representation" and "typically String-based" formulation from spec now
>> means "always String-based".
>> It seems to me that Converter introduces unnecessary dependency on
>> String-based representation - even ResponseWriter.write* accepts
>> java.lang.Object as value ....
>>
>> What I try to do is JSF-based server view with custom NOT-string based
>> protocol where "raw representations from client" can be java object like
>> Integer or more complex. Creating of:
>>
>> interface Converter2 {
>> Object getAsObject(FacesContext,UIComponent,Object)
>> Object getAsRepresentation(FacesContext,UIComponent,Object)
>> }
>>
>> solves my problem but I must reprogram significant part of JSF api.
>>
>> Does anybody know the backgroud of this? Yes, this is question for EG
>> but this mailing list more open ...
>>
>> Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
>> part of the problem)
>>
>> Regards,
>>
>> Kocicak
>>
>>
>>
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Mime
View raw message