eh, miss read. does not lack the NULL handling On Wed, Sep 8, 2010 at 11:22 AM, Matthias Wessendorf <mat...@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.k...@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
