Uploaded image for project: 'RichFaces'
  1. RichFaces
  2. RF-12177

"data-*" attributes in JSF components


    • Type: Feature Request
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Out of Date
    • Affects Version/s: 4.2.0.Final
    • Fix Version/s: None
    • Component/s: component
    • Labels:
    • Environment:



      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 :

      data="{key1:'value1', key2:'value2'}"

      will generate data-key1="value1" data-key2="value2" in the HTML tag.

      3) Nesting attributes is allowed :

      data="{key1:{sub1:'value11',sub2:'value12'}, key2:'value2'}"

      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



      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

      data="{key1:{nil:'value1', sub1:'value11', sub2:'value12'}}

      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 :

      data="{key1:{nil:{sub1:'value1'}, sub1:'value2'}}"

      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:

      data="{key1:{sub1:'#{bean.subvalue1}',sub2:'value12'}, key2:'#{bean.value2}'}"

      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 = "


      "}}, 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


      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 :

      data="#{bean.jsonArray} #{bean.firstMap} #{bean.secondMap}"


      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.

        Gliffy Diagrams




              • Assignee:
                paul.dijou Paul Dijou
              • Votes:
                2 Vote for this issue
                2 Start watching this issue


                • Created: