jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [1089-HTML5-data-*attributes] 20120525 REVISED PROPOSAL

From: Andy Schwartz <andy.schwartz_at_oracle.com>
Date: Sat, 26 May 2012 15:47:34 -0400

Gang -

Just passing along some more thoughts from Paul. (Thanks for your
continued participation in this thread Paul!)


On 5/26/12 1:18 PM, Paul Dijou wrote:
> 2012/5/26 Edward Burns <edward.burns_at_oracle.com
> <mailto:edward.burns_at_oracle.com>>
>
>
> SECTION: Revised proposal.
>
> 1. Drop <f:dataAttribute> [1]
>
>
> +1
>
>
>
> 2. Keep the text in the standard HTML_BASIC renderkit spec that talks
> about what to do with the UIComponent.DATA_ATTRIBUTES_KEY
> attribute. [2] Change the name of the key to
> PASS_THROUGH_ATTRIBUTES_KEY and amend all textual references to
> remove the "data-" ness because the data-ness (if any) will now be
> baked into the keys where it should have been all along.
> Linguistically, data-ness can be replaced with pass through-ness.
> Specify that the map must be Map<String, Object>. The text already
> allows EL for the values, but also allows EL for the keys. We will
> no longer be able to have EL for the keys with this design.
>
>
> +1, supporting any kind of attributes is far better than only data-*
> attributes.
>
>
>
> QUESTION: do we want to have a proper JavaBeans getter on UIComponent
> instead of UIComponent.PASS_THROUGH_ATTRIBUTES_KEY that is to be
> used as
> a key in UIComponents.getAttributes().get()?
>
>
> A getter would be cool.
>
>
>
> 3. Introduce a new facelet XMLNS
> http://java.sun.com/jsf/passThroughAttribute and modify the spec PDF
> section 10.3.2 to require that all tag handlers process any
> attributes with that namespace such that they get pushed into
> the Map<String, Object>.
>
>
> +1
>
>
>
> 4. Add <f:attributes>. This element has a "value" attribute that is a
> ValueExpression that points to Map<String,Object>. The spec for
> this
> element states that all entries in such a map are copied to the
> PASS_THROUGH_ATTRIBUTES_KEY map.
>
>
> +1. Following two ideas about improving <f:attributes> (none of them
> is vital but they can make your life easier) :
>
> - a "rendered" attribute to support conditionnal attributes. If
> present and evaluated to "false", the <f:attributes> is just ignored
> and none of its attributes are pushed inside the Map<String, Object>.
> One use case would be to have 2 set of attributes in a global bean and
> enable the good one depending on the status of the user :
> <f:attributes value="#{confBean.visitorConfiguration}"
> rendered="#{!user.isAdmin()}"/>
> <f:attributes value="#{confBean.adminConfiguration}"
> rendered="#{user.isAdmin()}"/>
>
> - a "prefix" attribute that would be added before all keys when
> inserting them inside the Map<String, Object>. The most obvious use
> case is "data-" attributes, but I can find others if you want.
> <f:attributes prefix="data-">{show:true, hide:false}</f:attributes>
> would result on "data-show="true" data-hide="false"".
>
>
> 5. Allow <f:attributes> to have body content that, if present, is
> interpreted as JSON. It is not valid to have both body content
> and a
> "value" attribute. If you want to do that sort of thing, have
> multiple <f:attributes>. In the case of multiple <f:attributes>
> elements, since each one will be copying its entries to the
> PASS_THROUGH_ATTRIBUTES_KEY map, each successive one will blindly
> overwrite any duplicate entries.
>
>
> +1 if you can use EL to specify JSON like :
>
> <f:attributes>#{confBean.jsonConfiguration}</f:attributes>
>
> or, really really better :
>
> <f:attributes>{show: #{confBean.showConfiguration}, hide:
> #{confBean.hideConfiguration}}</f:attributes>
>
> A question : does the <f:attributes> are inserted inside the
> Map<String, Object> before or after the attributes directly inside the
> tag with the new namespace ? If I have :
>
> <h:anything prefix:awesome="false">
> <f:attributes>{awesome:true}</f:attributes>
> </h:anything>
>
> what will be the value of the "awesome" key in the Map<String, Object>
> ? I guess it should be "true" because supporting HTML5 is truly
> awesome (and because <f:attributes> is written later and we said that
> the last one wins).
>
>
> If I missed anything PERTAINING ONLY TO PASS THRU ATTRIBUTES (not pass
> through elements), please reply and say so.
>
>
> By "pass through elements", you mean the stuff around supporting any
> kind of tag with <aStrangeTag id="test" jsfc="true"/>, right? Because
> I agree with Frank that this feature would be really cool for HTML
> developers that want to give a try on JSF but I also agree that it can
> be discuss in another topic since it's quite different.
>
> Regards,
>
> Paul.


Andy