Matthias Wessendorf píše v St 08. 09. 2010 v 11:22 +0200: > 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) yes, trinidad handles this situation best - mojarra casts to String in second case described in MYFACES-2910.
> 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 I use similar solution but it requires unique String representation <-> Object relation. This can be easily done for Numbers and other "primitive" types in Java but I must deal with types where unique String represenation does not exists or requires a lot of effort. So on JSF level conversion String <-> Object is unable to solve this problem - I simply need Object <-> Object conversion which is not supported yet. > > 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 > > > > > > > > > > > > >
