Hi,
> 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.
+1
> 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'}">
+1
> 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.
I guess the following is true: a JSF component renders a tag which is
dynamically used by a JQuery widget. Additional configuration data
(which jQuery needs to configure this widget) can be passed in with
the data params.
> (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.
+1
>> 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.
I would throw an exception if both are there (just like in Facelets:
you can't specify the same attribute twice, right?)
>
> 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?
+1
>
> 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?
merge
> Is our Map<String, Object> mutable?
If we merge, I guess no.
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces