Re: submittedValue vs. Converter.getAsObject

2011-03-03 Thread Martin Koci
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

Re: submittedValue vs. Converter.getAsObject

2010-09-23 Thread Martin Koci
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

Re: submittedValue vs. Converter.getAsObject

2010-09-23 Thread Leonardo Uribe
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

submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Koci
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

Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Matthias Wessendorf
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,

Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Koci
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

Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Marinschek
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

Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Marinschek
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

Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Leonardo Uribe
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

Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Matthias Wessendorf
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)

Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Martin Marinschek
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

Re: submittedValue vs. Converter.getAsObject

2010-09-08 Thread Leonardo Uribe
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