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 > >
