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

Mon Apr 16 09:36:18 EDT 2012

     [ https://issues.jboss.org/browse/RF-12177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukáš Fryč updated RF-12177:
----------------------------

    Description: 
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.

  was:
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 toughts 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 {{"{sub1:'value11',sub2:'value12'}"}}).

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 are 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 = "{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 data="{key1:#{bean.value}}" 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.

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