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