Re: submittedValue vs. Converter.getAsObject
Hi, is there any progress in this area? As I can see, there was no official response to this problem at jsr-314-open. Should we create request for JSF 2.2? Full thread: http://www.mail-archive.com/dev@myfaces.apache.org/msg48796.html I found another scenario where generic Object - Object conversion is useful: rowKey concept. Many renderkits use rowKey (Object) as replacement of indices (int) (DataModel.getRowKey instead of DataModel.getRowIndex). But a elegant type responsible for Object - rowKey (Object) is not available now. In my use cases, I need two different conversion chains: 1) for non-String based client: Object (a @Entity mostly) - rowKey (Object) and back. 2) HTML client: Object (@Entity) - rowKey (Object) (serves as key in trinidad CollectionModel for example) and then rowKey (Object) - clientRowKey (String) for HTML. In the second case, responsible types are: A) javax.faces.convert.Converter : Object (@Entity) - clientRowKey (String) B) org.apache.myfaces.trinidad.render.ClientRowKeyManager: rowKey (Object) - clientRowKey (String) C) ... this is the missing Object - Object conversion type. type A) - Converter can delegate it's resposibility to chain of C)s and one B). WDYT? Kočičák Hi Ok, good to know that. Anyway, I think a full solution should something like the proposed solution. Let's see what happen, and if it is not included maybe we could include it on a project in myfaces (myfaces commons or tomahawk maybe). regards, Leonardo Uribe Martin Koci píše v Čt 23. 09. 2010 v 21:40 +0200: Hi, I've just read Leonardo's post at jsr-314-open about this problem. FYI: I have finished prototype of JSF server side solution with non-String communication. It's based on custom renderkit and ResponseWriter implementation. I found only one major problem: this one discussed in this mail thread. Minor thing is string-based naming and meaning of ResponseWriter methods, because ResponseWriter is an abstract class describing an adapter to an underlying output mechanism for *character*-based output (from javadoc), but fortunately all methods accept Object as value. Regards, Kočičák Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500: Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
Hi, I've just read Leonardo's post at jsr-314-open about this problem. FYI: I have finished prototype of JSF server side solution with non-String communication. It's based on custom renderkit and ResponseWriter implementation. I found only one major problem: this one discussed in this mail thread. Minor thing is string-based naming and meaning of ResponseWriter methods, because ResponseWriter is an abstract class describing an adapter to an underlying output mechanism for *character*-based output (from javadoc), but fortunately all methods accept Object as value. Regards, Kočičák Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500: Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
Hi Ok, good to know that. Anyway, I think a full solution should something like the proposed solution. Let's see what happen, and if it is not included maybe we could include it on a project in myfaces (myfaces commons or tomahawk maybe). regards, Leonardo Uribe 2010/9/23 Martin Koci martin.kocicak.k...@gmail.com Hi, I've just read Leonardo's post at jsr-314-open about this problem. FYI: I have finished prototype of JSF server side solution with non-String communication. It's based on custom renderkit and ResponseWriter implementation. I found only one major problem: this one discussed in this mail thread. Minor thing is string-based naming and meaning of ResponseWriter methods, because ResponseWriter is an abstract class describing an adapter to an underlying output mechanism for *character*-based output (from javadoc), but fortunately all methods accept Object as value. Regards, Kočičák Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500: Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
submittedValue vs. Converter.getAsObject
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
Re: submittedValue vs. Converter.getAsObject
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./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
Re: submittedValue vs. Converter.getAsObject
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./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
Re: submittedValue vs. Converter.getAsObject
Hi Kocicak, So on JSF level conversion String - Object is unable to solve this problem - I simply need Object - Object conversion which is not supported yet. Yes, this is true - this is obviously a spec problem. If the submitted value is an object, it should also be allowed to convert it. A converter is more than just a string to object (and back) converter, it is an artefact which transforms information from its representation for output (and this output could be anything, and certainly doesn't have to be string based) to its representation which the business model (or also an artefact within JSF, like a validator) understands. So I agree. This hasn't come up so far cause nobody uses non string based output models for JSF. Note that my notion of a business converter (discussed on this mailing list a while ago) for converting between a business model representation and a representation in a JSF artefact like the renderer (e.g. you use joda.Date in the business model, but the JSF date picker renderer only understands the normal java date) is also hinting in the direction that such an additional converter API would be necessary. I discussed this with the EG (and also Ed privately), and there wasn't much interest for adding this. best regards, Martin best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
I discussed this with the EG (and also Ed privately), and there wasn't much interest for adding this. P.S.: it might however be useful to have this in the MyFaces implementation somehow. @Leonardo: did you actually provide a business-converter interface - we discussed about this? best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
Hi Martin
Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear
an interface like that was necessary but it is tied to java.util.Date in
this case:
/**
* Provide a bridge between the java.util.Date instance used by a component
* that receive date/time values and the business value used to represent
* the value.
*/
public interface DateBusinessConverter
{
/**
* Convert the java.util.Date instance calculated from submittedValue,
* so the resulting object will be used later as the converted value
* and validation.
*/
public Object getBusinessValue(FacesContext context,
UIComponent component,
java.util.Date value);
/**
* Used to retrieve the value stored in the business bean and convert
* it in a representation that the component (t:inputCalendar and
* t:inputDate for example)using this class can manipulate.
*/
public java.util.Date getDateValue(FacesContext context,
UIComponent component,
Object value);
}
This two components requires a date/time interface, and in this case the
choice was java.util.Date, to keep things simple, and to indicate that
internally, t:inputCalendar and t:inputDate only understands
java.util.Date for rendering.
best regards,
Leonardo
2010/9/8 Martin Marinschek mmarinsc...@apache.org
I discussed this with the EG (and also Ed privately),
and there wasn't much interest for adding this.
P.S.: it might however be useful to have this in the MyFaces
implementation somehow.
@Leonardo: did you actually provide a business-converter interface -
we discussed about this?
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
In Trinidad internal package there is a TypeConverter, use in the
Date/Number converter (internals) of Trinidad.
has a factory and some more stuff, perhaps worth to check (they were
introduced - looong time ago - to support the
mentioned oracle types, from the binding layer)
-M
On Wed, Sep 8, 2010 at 4:27 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi Martin
Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear
an interface like that was necessary but it is tied to java.util.Date in
this case:
/**
* Provide a bridge between the java.util.Date instance used by a component
* that receive date/time values and the business value used to represent
* the value.
*/
public interface DateBusinessConverter
{
/**
* Convert the java.util.Date instance calculated from submittedValue,
* so the resulting object will be used later as the converted value
* and validation.
*/
public Object getBusinessValue(FacesContext context,
UIComponent component,
java.util.Date value);
/**
* Used to retrieve the value stored in the business bean and convert
* it in a representation that the component (t:inputCalendar and
* t:inputDate for example)using this class can manipulate.
*/
public java.util.Date getDateValue(FacesContext context,
UIComponent component,
Object value);
}
This two components requires a date/time interface, and in this case the
choice was java.util.Date, to keep things simple, and to indicate that
internally, t:inputCalendar and t:inputDate only understands
java.util.Date for rendering.
best regards,
Leonardo
2010/9/8 Martin Marinschek mmarinsc...@apache.org
I discussed this with the EG (and also Ed privately),
and there wasn't much interest for adding this.
P.S.: it might however be useful to have this in the MyFaces
implementation somehow.
@Leonardo: did you actually provide a business-converter interface -
we discussed about this?
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: submittedValue vs. Converter.getAsObject
Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
