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