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 2010/09/07 23:05:19 UTC
submittedValue vs. Converter.getAsObject
Hi,
maybe this is a stupid question but:
>>From UIInput javadoc:
... decoded value of this component, usually but >>>not necessarily a
String<<<, must be stored - but not yet converted - using
setSubmittedValue() ....
from UIInput.getConvertedValue:
... and the submitted value is a >>>String<<<, locate a Converter as
follows
Question: why is Converter tied only to String? Whole specification
speaks about submitted value as of "raw representation of value from
client" but not necessarily String. And 3.3 Conversion Model: "This
section describes the facilities provided by JavaServer Faces to support
type conversion between server-side Java objects and their (typically
String-based) representation in presentation markup."
But Converter.getAsObject expects only String as this "raw
representation" and "typically String-based" formulation from spec now
means "always String-based".
It seems to me that Converter introduces unnecessary dependency on
String-based representation - even ResponseWriter.write* accepts
java.lang.Object as value ....
What I try to do is JSF-based server view with custom NOT-string based
protocol where "raw representations from client" can be java object like
Integer or more complex. Creating of:
interface Converter2 {
Object getAsObject(FacesContext,UIComponent,Object)
Object getAsRepresentation(FacesContext,UIComponent,Object)
}
solves my problem but I must reprogram significant part of JSF api.
Does anybody know the backgroud of this? Yes, this is question for EG
but this mailing list more open ...
Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
part of the problem)
Regards,
Kocicak
Re: submittedValue vs. Converter.getAsObject
Posted by Matthias Wessendorf <ma...@apache.org>.
eh, miss read. does not lack the NULL handling
On Wed, Sep 8, 2010 at 11:22 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> Hello,
>
> in Trinidad we don't cast to String:
>
> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/EditableValueRenderer.java?view=annotate
>
> (see line 133->135)
>
> This is because of supporting the "oracle adf numbers", like:
> http://download.oracle.com/docs/cd/E12839_01/apirefs.1111/e10655/index.html?oracle/jbo/domain/Number.html
>
> The fix is simple: call toString() instead of doing the cast.
>
> However, I think your patch misses the case of tolerating NULL (new w/ jsf2)
>
> -Matthias
>
> On Tue, Sep 7, 2010 at 11:05 PM, Martin Koci
> <ma...@gmail.com> wrote:
>> Hi,
>>
>> maybe this is a stupid question but:
>>
>> >From UIInput javadoc:
>>
>> ... decoded value of this component, usually but >>>not necessarily a
>> String<<<, must be stored - but not yet converted - using
>> setSubmittedValue() ....
>>
>>
>> from UIInput.getConvertedValue:
>>
>> ... and the submitted value is a >>>String<<<, locate a Converter as
>> follows
>>
>> Question: why is Converter tied only to String? Whole specification
>> speaks about submitted value as of "raw representation of value from
>> client" but not necessarily String. And 3.3 Conversion Model: "This
>> section describes the facilities provided by JavaServer Faces to support
>> type conversion between server-side Java objects and their (typically
>> String-based) representation in presentation markup."
>> But Converter.getAsObject expects only String as this "raw
>> representation" and "typically String-based" formulation from spec now
>> means "always String-based".
>> It seems to me that Converter introduces unnecessary dependency on
>> String-based representation - even ResponseWriter.write* accepts
>> java.lang.Object as value ....
>>
>> What I try to do is JSF-based server view with custom NOT-string based
>> protocol where "raw representations from client" can be java object like
>> Integer or more complex. Creating of:
>>
>> interface Converter2 {
>> Object getAsObject(FacesContext,UIComponent,Object)
>> Object getAsRepresentation(FacesContext,UIComponent,Object)
>> }
>>
>> solves my problem but I must reprogram significant part of JSF api.
>>
>> Does anybody know the backgroud of this? Yes, this is question for EG
>> but this mailing list more open ...
>>
>> Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
>> part of the problem)
>>
>> Regards,
>>
>> Kocicak
>>
>>
>>
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: submittedValue vs. Converter.getAsObject
Posted by Matthias Wessendorf <ma...@apache.org>.
In Trinidad internal package there is a TypeConverter, use in the
Date/Number converter (internals) of Trinidad.
has a factory and some more stuff, perhaps worth to check (they were
introduced - looooooooooooooooooooooong time ago - to support the
mentioned "oracle types", from the binding layer)
-M
On Wed, Sep 8, 2010 at 4:27 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi Martin
>
> 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:
>
> /**
> * Provide a bridge between the java.util.Date instance used by a component
> * that receive date/time values and the "business" value used to represent
> * the value.
> */
> public interface DateBusinessConverter
> {
> /**
> * Convert the java.util.Date instance calculated from submittedValue,
> * so the resulting object will be used later as the converted value
> * and validation.
> */
> public Object getBusinessValue(FacesContext context,
> UIComponent component,
> java.util.Date value);
>
> /**
> * Used to retrieve the value stored in the business bean and convert
> * it in a representation that the component (t:inputCalendar and
> * t:inputDate for example)using this class can manipulate.
> */
> public java.util.Date getDateValue(FacesContext context,
> UIComponent component,
> Object value);
> }
>
> This two components requires a date/time interface, and in this case the
> choice was java.util.Date, to keep things simple, and to indicate that
> internally, t:inputCalendar and t:inputDate only "understands"
> java.util.Date for rendering.
>
> best regards,
>
> Leonardo
>
> 2010/9/8 Martin Marinschek <mm...@apache.org>
>>
>> > I discussed this with the EG (and also Ed privately),
>> > and there wasn't much interest for adding this.
>>
>> P.S.: it might however be useful to have this in the MyFaces
>> implementation somehow.
>>
>> @Leonardo: did you actually provide a business-converter interface -
>> we discussed about this?
>>
>> best regards,
>>
>> Martin
>>
>> > --
>> >
>> > http://www.irian.at
>> >
>> > Your JSF powerhouse -
>> > JSF Consulting, Development and
>> > Courses in English and German
>> >
>> > Professional Support for Apache MyFaces
>> >
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: submittedValue vs. Converter.getAsObject
Posted by Martin Koci <ma...@gmail.com>.
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
> >
> >
>
Re: submittedValue vs. Converter.getAsObject
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <ma...@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 <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
> >
> >
>
>
>
Re: submittedValue vs. Converter.getAsObject
Posted by Martin Koci <ma...@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 <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
>
>
Re: submittedValue vs. Converter.getAsObject
Posted by Leonardo Uribe <lu...@gmail.com>.
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
>
Re: submittedValue vs. Converter.getAsObject
Posted by 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.
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi Martin
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:
/**
* Provide a bridge between the java.util.Date instance used by a component
* that receive date/time values and the "business" value used to represent
* the value.
*/
public interface DateBusinessConverter
{
/**
* Convert the java.util.Date instance calculated from submittedValue,
* so the resulting object will be used later as the converted value
* and validation.
*/
public Object getBusinessValue(FacesContext context,
UIComponent component,
java.util.Date value);
/**
* Used to retrieve the value stored in the business bean and convert
* it in a representation that the component (t:inputCalendar and
* t:inputDate for example)using this class can manipulate.
*/
public java.util.Date getDateValue(FacesContext context,
UIComponent component,
Object value);
}
This two components requires a date/time interface, and in this case the
choice was java.util.Date, to keep things simple, and to indicate that
internally, t:inputCalendar and t:inputDate only "understands"
java.util.Date for rendering.
best regards,
Leonardo
2010/9/8 Martin Marinschek <mm...@apache.org>
> > I discussed this with the EG (and also Ed privately),
> > and there wasn't much interest for adding this.
>
> P.S.: it might however be useful to have this in the MyFaces
> implementation somehow.
>
> @Leonardo: did you actually provide a business-converter interface -
> we discussed about this?
>
> best regards,
>
> Martin
>
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: submittedValue vs. Converter.getAsObject
Posted by Martin Marinschek <mm...@apache.org>.
> I discussed this with the EG (and also Ed privately),
> and there wasn't much interest for adding this.
P.S.: it might however be useful to have this in the MyFaces
implementation somehow.
@Leonardo: did you actually provide a business-converter interface -
we discussed about this?
best regards,
Martin
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
Posted by Martin Marinschek <mm...@apache.org>.
Hi Kocicak,
> So on JSF level conversion String <-> Object is unable to solve this
> problem - I simply need Object <-> Object conversion which is not
> supported yet.
Yes, this is true - this is obviously a spec problem.
If the submitted value is an object, it should also be allowed to
convert it. A converter is more than just a string to object (and
back) converter, it is an artefact which transforms information from
its representation for output (and this output could be anything, and
certainly doesn't have to be string based) to its representation which
the business model (or also an artefact within JSF, like a validator)
understands.
So I agree. This hasn't come up so far cause nobody uses non string
based output models for JSF.
Note that my notion of a business converter (discussed on this mailing
list a while ago) for converting between a business model
representation and a representation in a JSF artefact like the
renderer (e.g. you use joda.Date in the business model, but the JSF
date picker renderer only understands the normal java date) is also
hinting in the direction that such an additional converter API would
be necessary. I discussed this with the EG (and also Ed privately),
and there wasn't much interest for adding this.
best regards,
Martin
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
Posted by Martin Koci <ma...@gmail.com>.
Matthias Wessendorf píše v St 08. 09. 2010 v 11:22 +0200:
> Hello,
>
> in Trinidad we don't cast to String:
>
> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/EditableValueRenderer.java?view=annotate
>
> (see line 133->135)
yes, trinidad handles this situation best - mojarra casts to String in
second case described in MYFACES-2910.
> This is because of supporting the "oracle adf numbers", like:
> http://download.oracle.com/docs/cd/E12839_01/apirefs.1111/e10655/index.html?oracle/jbo/domain/Number.html
I use similar solution but it requires unique String representation <->
Object relation. This can be easily done for Numbers and other
"primitive" types in Java but I must deal with types where unique String
represenation does not exists or requires a lot of effort.
So on JSF level conversion String <-> Object is unable to solve this
problem - I simply need Object <-> Object conversion which is not
supported yet.
>
> The fix is simple: call toString() instead of doing the cast.
>
> However, I think your patch misses the case of tolerating NULL (new w/ jsf2)
>
> -Matthias
>
> On Tue, Sep 7, 2010 at 11:05 PM, Martin Koci
> <ma...@gmail.com> wrote:
> > Hi,
> >
> > maybe this is a stupid question but:
> >
> > >From UIInput javadoc:
> >
> > ... decoded value of this component, usually but >>>not necessarily a
> > String<<<, must be stored - but not yet converted - using
> > setSubmittedValue() ....
> >
> >
> > from UIInput.getConvertedValue:
> >
> > ... and the submitted value is a >>>String<<<, locate a Converter as
> > follows
> >
> > Question: why is Converter tied only to String? Whole specification
> > speaks about submitted value as of "raw representation of value from
> > client" but not necessarily String. And 3.3 Conversion Model: "This
> > section describes the facilities provided by JavaServer Faces to support
> > type conversion between server-side Java objects and their (typically
> > String-based) representation in presentation markup."
> > But Converter.getAsObject expects only String as this "raw
> > representation" and "typically String-based" formulation from spec now
> > means "always String-based".
> > It seems to me that Converter introduces unnecessary dependency on
> > String-based representation - even ResponseWriter.write* accepts
> > java.lang.Object as value ....
> >
> > What I try to do is JSF-based server view with custom NOT-string based
> > protocol where "raw representations from client" can be java object like
> > Integer or more complex. Creating of:
> >
> > interface Converter2 {
> > Object getAsObject(FacesContext,UIComponent,Object)
> > Object getAsRepresentation(FacesContext,UIComponent,Object)
> > }
> >
> > solves my problem but I must reprogram significant part of JSF api.
> >
> > Does anybody know the backgroud of this? Yes, this is question for EG
> > but this mailing list more open ...
> >
> > Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
> > part of the problem)
> >
> > Regards,
> >
> > Kocicak
> >
> >
> >
> >
> >
>
>
>
Re: submittedValue vs. Converter.getAsObject
Posted by Matthias Wessendorf <ma...@apache.org>.
Hello,
in Trinidad we don't cast to String:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/EditableValueRenderer.java?view=annotate
(see line 133->135)
This is because of supporting the "oracle adf numbers", like:
http://download.oracle.com/docs/cd/E12839_01/apirefs.1111/e10655/index.html?oracle/jbo/domain/Number.html
The fix is simple: call toString() instead of doing the cast.
However, I think your patch misses the case of tolerating NULL (new w/ jsf2)
-Matthias
On Tue, Sep 7, 2010 at 11:05 PM, Martin Koci
<ma...@gmail.com> wrote:
> Hi,
>
> maybe this is a stupid question but:
>
> >From UIInput javadoc:
>
> ... decoded value of this component, usually but >>>not necessarily a
> String<<<, must be stored - but not yet converted - using
> setSubmittedValue() ....
>
>
> from UIInput.getConvertedValue:
>
> ... and the submitted value is a >>>String<<<, locate a Converter as
> follows
>
> Question: why is Converter tied only to String? Whole specification
> speaks about submitted value as of "raw representation of value from
> client" but not necessarily String. And 3.3 Conversion Model: "This
> section describes the facilities provided by JavaServer Faces to support
> type conversion between server-side Java objects and their (typically
> String-based) representation in presentation markup."
> But Converter.getAsObject expects only String as this "raw
> representation" and "typically String-based" formulation from spec now
> means "always String-based".
> It seems to me that Converter introduces unnecessary dependency on
> String-based representation - even ResponseWriter.write* accepts
> java.lang.Object as value ....
>
> What I try to do is JSF-based server view with custom NOT-string based
> protocol where "raw representations from client" can be java object like
> Integer or more complex. Creating of:
>
> interface Converter2 {
> Object getAsObject(FacesContext,UIComponent,Object)
> Object getAsRepresentation(FacesContext,UIComponent,Object)
> }
>
> solves my problem but I must reprogram significant part of JSF api.
>
> Does anybody know the backgroud of this? Yes, this is question for EG
> but this mailing list more open ...
>
> Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
> part of the problem)
>
> Regards,
>
> Kocicak
>
>
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf