myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Koci <>
Subject submittedValue vs. Converter.getAsObject
Date Tue, 07 Sep 2010 21:05:19 GMT

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

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: (only
part of the problem)



View raw message