Gang -
Some more thoughts from Paul:
> Hi there,
>
> If you go with a new tag like <f:dataAttribute>, I agree you should
> keep as minimal attributes as possible. Like a "value" one that
> support anything (String, JSON, Map, EL, ...) and eventually a "name"
> one to create a pair key/value.
>
> About precedence, I think the final purpose is to populate a
> Map<String, String> where the key is the data-* name and the value is
> the plain text value that will be put on the generated HTML tag. So if
> a JSF component has several <f:dataAttribute>, just read them from the
> first one to the last one and put their values on the Map, overriding
> existing keys without question. This way, you authorized users to
> easily do whatever they want.
>
> For example, the first <f:dataAttribute> can be using JSON with the
> default configuration for all data-* attributes. Then, for some
> particuliar JSF components, you can add some <f:dataAttribute
> name="..." value="..."> to override some data-* attributes in this
> case. So it would be a merge with no errors. Quite easy, quite powerfull.
>
> About JSON versus Map, I understand because Java rocks :). I think the
> best way should be to support both, it shouldn't be that hard (I
> guess...). One strong point for JSON is that you can write it directly
> in you XHTML page, not sure you can do it with a Map.
>
> jQuery UI + EL comes into action for example when you use REST or CDI
> producers to serve your JSON configuration for jQuery UI widgets so
> you can retrieve it using EL in your JSF components (the ones that
> will generate the widgets).
>
> Finally, all comes to several ways to pass data-* attributes and
> merging them before generating the HTML tag. The easy way
> <f:dataAttribute name="..." value="..."/>. The Java way
> <f:dataAttribute value="#{bean.map}"/>. The "jQuery" / "Javascript"
> way <f:dataAttribute value="{json}" />. And with no limit
> <f:dataAttribute value="#{bean.json}" />.
>
> Regards,
>
> Paul.
Andy