On 5/21/12 10:06 AM, Edward Burns wrote:
> Rather than put "data" everywhere, let's just put it on
> <f:dataAttribute>. So you'd have
>
> <f:dataAttribute name="foo" value="bar">
>
> or
>
> <f:dataAttribute json="{ foo : bar}" />
>
>
I am not happy with using a single tag to support two very different
cases with mutually exclusive attributes. If we are breaking this out
into a tag, I would much prefer that we add a second <f:dataAttributes>
tag for the multiple data-* case.
Also, I am not happy with the attribute name "json". When EL-binding
this value, we need to be able to bind directly to a Map<String, Object>.
That is, we need to support something like:
<f:dataAttributes json="#{foo.bonusDataAttrs}">
Where #{foo.bonusDataAttrs} evaluates to a Map<String, Object>.
The name "json" does not make sense here.
If people feel that it is important to be able to specify name/value
pairs inline, we can go witih JSON for our literal text representation.
However, just because we happen to use JSON for specifying literal
versions of maps, that doesn't mean that we should promote this type
information into the attribute name.
That would be kind of like if we had specified:
<f:ajax whiteSpaceSeparatedIds="foo bar"/>
Instead of:
<f:ajax render="foo bar"/>
We need to abstract away the literal type info from the attribute name.
So, for example, I would prefer something like:
<f:dataAttributes value="#{foo.bonusDataAttrs}">
<f:dataAttributes value="{foo:'bar'}">
Paul had made a case for supporting EL binding directly to JSON strings:
> But if I should keep only one, it would be JSON only because it's
easy to transform a Map in a
> JSON array, but when I have real JSON (like when I have the
configuration of a jQuery UI widget),
> it's a bit heavy to be forced to use a Java method to transform it in
a Map.
I don't quite get this - ie. I don't understand how jQuery comes into
the picture when EL binding to a Java managed bean.
(Paul, could you maybe chime in with more details? Feel free to send
mail directly to me and I'll forward to the group.)
Perhaps there is a case for supporting this. However, even if there is,
I am totally opposed to making this mandatory. We cannot tell Java
developers that in order to produce a Map<String, Object>, they must
first construct a JSON string.
> Of course, EL expressions are valid en all places.
>
> For completeness, we'd need to decide which takes precedence, and in
> this case it's simpler to say that if the json attribute is present, all
> other attributes are ignored.
>
If we go with two tags:
<f:dataAttributes value="#{foo.bonusDataAttrs}">
<f:dataAttribute name="foo" value="bar"/>
I would think that we would spec this such that <f:dataAttribute> would
win over the equivalent value in the EL-bound map.
Though I am a bit confused about what behavior we want for our
Map<String, Object> more generally...
Would the above tags result in a Map<String, Object> that contains all
of the values specified in the EL-bound map + all of the explicitly
specified <f:dataAttribute> values?
Would we support multiple <f:dataAttributes> tags for a single
component? For example, in this case:
<f:dataAttributes value="#{foo.bonusDataAttrs}">
<f:dataAttributes value="#{bar.morebonusDataAttrs}">
Do we merge the maps? Last one wins? Unsupported?
Is our Map<String, Object> mutable?
Andy
> Ed
>