8:19 a.m.
Paul Dijou created RF-12177:
-------------------------------
Summary: "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
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.
--
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