users@javaserverfaces-spec-public.java.net

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

From: Andy Schwartz <andy.schwartz_at_oracle.com>
Date: Fri, 18 May 2012 22:07:47 -0400

Gang -

More thoughts on this topic from Paul:

> From: Paul Dijou
> To: jsr344-experts_at_javaserverfaces-spec-public.java.net
> <mailto:jsr344-experts_at_javaserverfaces-spec-public.java.net>
> Cc:
> Date: Fri, 18 May 2012 22:35:11 +0200
> Subject: Re: [jsr344-experts mirror] [jsr344-experts] Re: Re: Re:
> [1089-HTML5-data-*attributes] PROPOSAL
> Hi Andy,
>
> I agree that both approach target different use case. That's why I'm
> fine with having both of them.
>
> Why JSON and not a Java Map ? In fact, if you read the first comment
> here : https://issues.jboss.org/browse/RF-12177 , you will see that my
> full proposal include Map, nested Map, JSON, plain text (proposed by
> Lukas in the 2nd comment), and any combo of that.
>
> But if I should keep only one, it would be JSON only because it's easy
> to transform a Map in a JSON array, but when I have real JSON (like
> when I have the configuration of a jQuery UI widget), it's a bit heavy
> to be forced to use a Java method to transform it in a Map.
>
> But at the end, I totally agree that the final purpose is only to
> populate a Map<String, String> for the component.
>
> About nesting, that's not a prior feature to be honnest, but it can be
> usefull sometime. Ed example was overkill (but fun). Generally, you
> only have two or three levels when you nest. One use case is to group
> data-* attributes. Like :
>
> <x:component data="{show : {speed : fast, effect : fade}, hide :
> {speed : medium, effect : fade}}" />
>
> It's more easy to read rather than having to write fully each
> attribute. Next, let's say you want all your components to have the
> same configuration for the "show" part. So your put this configuration
> somewhere centralized (like in an @ApplicationScope bean), and now you
> have :
>
> <x:component data="{show : #{bean.showConfiguration}, hide : {speed :
> medium, effect : fade}}" />
>
> Not so bad isn't it ? You could say you could have done the same with :
>
> <x:component data="{show-speed : #{bean.showSpeedConfiguration},
> show-effect : #{bean.showEffectConfiguration}, hide : {speed : medium,
> effect : fade}}" />
>
> True (even if there is like three times more caracters! Haha!). But
> what if tomorrow you need to add a new sub-attribute to the "show"
> part ? Like "data-show-delay" ? You would need to add it to all your
> components. If you were using the nested form, you would only need to
> add it to your global configuration and you would be done. So, like I
> say, it's not vital, but it can be usefull so I don't see any reason
> not to support it.
>
> By the way, that example also demonstrates why it can be usefull to
> have EL in an inline JSON array.
>
> But I have never written a specification (well, only for small
> projects, not for something big like JSF), so maybe my vision of "the
> more ways to pass data, the best for developpers" is wrong.
>
> About the name of the attribute "data", I can disagree that it might
> be a bit confusing but I hope people read a bit of doc before using
> JSF :) I'm quite fine with both names, even if I would prefer "data"
> because it's simplier and I already know what it means.
>
> Regards,
>
> Paul.

Andy