Yes, adding the flag sounds reasonable to me then, just to be spec compliant.
Cheers, Bruno On 28/04/07, Adam Winer <[EMAIL PROTECTED]> 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
