[richfaces-issues] [JBoss JIRA] (RF-12177) "data-*" attributes in JSF components

[Paul Dijou (JIRA)]

    [ https://issues.jboss.org/browse/RF-12177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12684524#comment-12684524 ] 

Paul Dijou commented on RF-12177:
---------------------------------

Thanks a lot for the better formatting Lukáš.

HAML syntax is using quite a similar approach. It's not exactly JSON, but not far away. For example, having :

{code:xml}
%a{:data => {:tooltip => "A tooltip", :properties => {:effect => "fade", :positon => "bottom"} } }
{code}

will generate :

{code:xml}
<a data-tooltip="A tooltip" data-properties-effect="fade" data-properties-position="bottom">
{code}

See reference documentation : http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#html5_custom_data_attributes

I don't know any other framework / syntax using JSON in "data" attribute so far.

I guess nesting attributes are not the most important part. But still, can be great if you use the {{.data()}} method of jQuery (see : http://api.jquery.com/data/ ) since it will split all your "data-*" attributes around "-" caracter and make nested arrays.

Also, it would allow you to write :

{code:xml}
data="key1: #{bean.allKey1subProperties}"
{code}
                
> "data-*" attributes in JSF components
> -------------------------------------
>
>                 Key: RF-12177
>                 URL: https://issues.jboss.org/browse/RF-12177
>             Project: RichFaces
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: component
>    Affects Versions: 4.2.0.Final
>         Environment: Any
>            Reporter: Paul Dijou
>              Labels: attribute, html5, jsf
>
> Hi there,
> First of all, sorry for all native English speakers, maybe your eyes will suffer from my grammar...
> A few days ago, I tried to use Bootstrap with JSF and faced quite an issue by not having any "data-*" attributes in JSF composents. Since Bootstrap, and more generally HTML5, relies a lot on this type of attribute, I was thinking it would be great to have them in JSF.
> My first tought was to propose the idea to RichFaces but then I aimed directly to JSF spec and here we are : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1089
> Still, if you are okay for it, it would be great to discuss about this issue (maybe during a RichFaces meeting) in order to propose something more documented than just an idea to JSF spec. I could try to do that alone, but having feedback from JSF experts would be really better and result in more precise and clever proposal.
> So far, here are my thoughts about the problem :
> 1) Only one new attribute {{"data"}} in JSF tags but it will create several {{"data-*"}} attributs in the HTML tag rendered depending on its value.
> 2) Using *JSON format* to provide all {{key => value}} pairs. For example : 
> {code}data="{key1:'value1', key2:'value2'}"{code}
> will generate {{data-key1="value1" data-key2="value2"}} in the HTML tag.
> 3) *Nesting attributes* is allowed :
> {code}data="{key1:{sub1:'value11',sub2:'value12'}, key2:'value2'}"{code}
> will generate {{data-key1-sub1="value11" data-key1-sub2="value12" data-key2="value2"}}
> 4) Wait, that means there is no way to have both {{data-key1="value1"}} and {{data-key1-sub1="value11"}} since {{"key1"}} key can only have one value : a real value (like {{"value1"}}) or an array for nesting purpose (like 
> {code}"{sub1:'value11',sub2:'value12'}"{code}.
> I think the best way to solve this is to have a specific key that will add no suffix even in a nested array. Let's call this key *'nil' or 'null'* or wathever. So
> {code}data="{key1:{nil:'value1', sub1:'value11', sub2:'value12'}}{code}
> would generate {{data-key1="value1"}}  {{data-key1-sub1="value11" data-key1-sub2="value12"}}
> Warning : this special key should no accept an array as value. Or conflicts would appears really quickly. Like having : 
> {code}data="{key1:{nil:{sub1:'value1'}, sub1:'value2'}}"{code}
> would generate {{data-key1-sub1="value1" data-key1-sub1="value2"}}... Error !
> 5) Of course, *EL is allowed* inside the JSON format. So, this is correct:
> {code}data="{key1:{sub1:'#{bean.subvalue1}',sub2:'value12'}, key2:'#{bean.value2}'}"{code}
> The return type of the EL must be *String*. But it can be plain String for a real value or an array in JSON format for nesting purpose.
> If {{bean.subvalue1 = "value11"}} and {{bean.value2 = "{sub1:'value21'}"}}, then the precedent example will generate : {{data-key1-sub1="value11" data-key1-sub2="value12" data-key2-sub1="value21"}}
> 6) That was the first part. Next, what about a more *Java centric approach* ? "data" attribut could also accept a {{Map<String, Object>}} as value. For each {{Entry<String,Object>}}, it would add the String key as a suffix of "data" and calling {{Object#toString()}} method for the value. Only exception : if {{Object}} is an instance of {{Map}}, then it will nest the {{Map}}. The special key for non-suffix adding could be null value or an empty {{String}}.
> 7) Perhaps, also, try to do combos ! Like having 
> {code}data="{key1:#{bean.value}}"{code}
> where *bean.value* is a {{Map<String,Object>}} that should be interpreted as a JSON array for nesting purpose.
> 8) Or combo fusion ! Having the possibility to add several entry point on the "data" attribute, separated by whitespace, before merging them all.
> For exemple, having : 
> {code}data="#{bean.jsonArray} #{bean.firstMap} #{bean.secondMap}"}}{code},
> where {{bean.jsonArray}} is a String with JSON format, and {{bean.firstMap}} and {{bean.secondMap}} are {{Map<String,Object>}}. But it would be open door to unique attribute name conflicts.
> That's all. I'm really looking forward to any feedback or brainstorming in Irc. Maybe, just another idea, if I have time (or anyone else), try to submit some code doing that to RichFaces. It could help people who are using RichFaces 4 but won't be able to migrate to JSF 2.2 yet and still need "data-*" attributes.
> Thanks for reading.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira