(ADFFACES-377) JSF 1.2: EL binding to null Strings

[Adam Winer <aw...@gmail.com>]

Bruno commented on this JIRA issue:

> For MyFaces 1.2 TLD compliance we really need to be able to have things like
>
> <deferred-value>
>    <type>java.lang.String</type>
> </deferred-value>
>
> (for instance, the dataTable "var" attribute)
>
> As well as other deferred value types, such as javax.faces.component.UIComponent.

For most deferred value types, the plugin does generate the
correct deferred value type.  It sounds like there's two issues
here:  for "binding", we're not creating a deferred value type
of UIComponent (though, functionally, it's pointless as
coercion is impossible).  Then, for "var", we're not generating
a type of java.lang.String.

As background, when we did specify deferred-value for
String, we ran into the appallingly poor EL specification
for type coercion of strings - null is coerced to the
empty string.  That is a big, big problem for Trinidad,
and any taglib really, as the empty string and null
are frequently handled totally differently.  So you either
give up automatic coercion, or give up recognizing the
difference between the two.  The latter's unacceptable
as a broad policy.

Since we can't just put back <type>java.lang.String</type>
in all places.  I think we could have a metadata flag that
forces the deferred-value to java.lang.String for spec
compliance, but I'd recommend against using it anywhere
that your hands aren't completely tied.

Cheers,
Adam

Re: (ADFFACES-377) JSF 1.2: EL binding to null Strings

[Bruno Aranda <br...@gmail.com>]

Yes, adding the flag sounds reasonable to me then, just to be spec compliant.

Cheers,

Bruno

On 28/04/07, Adam Winer <aw...@gmail.com> wrote:
> Bruno commented on this JIRA issue:
>
> > For MyFaces 1.2 TLD compliance we really need to be able to have things like
> >
> > <deferred-value>
> >    <type>java.lang.String</type>
> > </deferred-value>
> >
> > (for instance, the dataTable "var" attribute)
> >
> > As well as other deferred value types, such as javax.faces.component.UIComponent.
>
> For most deferred value types, the plugin does generate the
> correct deferred value type.  It sounds like there's two issues
> here:  for "binding", we're not creating a deferred value type
> of UIComponent (though, functionally, it's pointless as
> coercion is impossible).  Then, for "var", we're not generating
> a type of java.lang.String.
>
> As background, when we did specify deferred-value for
> String, we ran into the appallingly poor EL specification
> for type coercion of strings - null is coerced to the
> empty string.  That is a big, big problem for Trinidad,
> and any taglib really, as the empty string and null
> are frequently handled totally differently.  So you either
> give up automatic coercion, or give up recognizing the
> difference between the two.  The latter's unacceptable
> as a broad policy.
>
> Since we can't just put back <type>java.lang.String</type>
> in all places.  I think we could have a metadata flag that
> forces the deferred-value to java.lang.String for spec
> compliance, but I'd recommend against using it anywhere
> that your hands aren't completely tied.
>
> Cheers,
> Adam
>