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


Reply via email to