You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Koci <ma...@gmail.com> on 2011/03/03 10:34:16 UTC
Re: submittedValue vs. Converter.getAsObject
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 <mm...@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
> >
> >
>