On 23.05.2012, at 15:53, Andy Schwartz <andy.schwartz_at_oracle.com> wrote:
> On 5/22/12 11:11 PM, Phil Webb wrote:
>> Could the idea of pass-though attributes also apply to components? Using the h:panelGroup to render a different output seems a little odd to me, but perhaps a specific prefix could be used for dynamic components, so:
>>
>> <h:panelGroup layout="ul" type="disc" id="foo"/>
>>
>> becomes:
>>
>> <d:ui type="disc" id="foo"/>
>>
>> Anything prefixed with the 'd:' schema gets created as a dynamic pass-though component.
>
> Interesting. Just to be sure... the "<d:ui>" in your example was meant to be "<d:ul>", right?
>
> Another option would be to add a single generic component which allows the element name to be specified as an attribute, eg:
>
> <h:element name="ul">
This would also be ok for me.
>
> Not quite as nifty as your namespace-based approach I suppose, though I prefer either of these over mucking with <h:panelGroup>.
>
> (I agree with Brian that this looks like it should be tackled as a separate issue.)
It has definitely nothing to do with the attributes but would be only a little enhancement without the render through attributes.
It has actually something to do with HTML5 because, if we had this generic element, we would also have all new HTML5 elements, which have only client side impact.
>> Perhaps a prefix should also be used for unknown attributes to allow tooling some hints that breaking the facelet schema in this case is permitted.
>>
>> If pass-though attributes do become part of the spec they should probably be opt-in. There may be existing code currently using additional attributes for their own ends. I believe that UIComponent.getValueExpression() can be used to get any attribute, so some developers may have attributes in their XHTML that they use currently but they absolutely do not want exposed to the browser.
>>
>
> Yep. I have the same concern. Currently Facelets dumps unspecified attributes into the UIComponent's attributes map. Existing apps are using this for their own purposes and would be negatively impacted if we simply started passing all of these through to the client.
>
> I like your namespaced attribute recommendation.
>
> I really like the idea of tackling the problem generically, rather than limiting the focus to the data-* attributes.
>
> I also like Frank's suggestion that we allow this to be used to override attributes that are rendered by the Renderer:
>
>> <h:inputText value="#{foo.bar}" type="email"/> would be rendered as <input type="email" value=""/> because the unknown attribute overrides it.
>
> Though we'll want to find a way to hide this complexity from Renderer implementations - ie. ideally Renderers would not need to explicitly check for the presence of an attribute override every time an attribute is written to the ResponseWriter. I think that this means that we'll want this complexity to live in the ResponseWriter. It's possible that doing so will have some implications for the specification.
+1, that way, I added support for placeholder and data-xxx attributes in my last project.
> One case that does not seem to be covered by the pass-through attribute approach is the original case that Paul raised - ie. the ability to specify an arbitrary # of possibly dynamically determined bonus attributes. If we want to tackle this case, seems like we would still be stuck with adding some Map<String, Object>-based attribute, eg:
>
> <h:panelGroup passThruAttributes="#{foo.bonusAttrs}"/>
+1, my proposal was just to ease life of HTML developers, who don't want to put their attributes into a backing bean, because often they don't have the skills to do so. And the more complex the clients get the more specialized the frontend developers will be and the less they know Java.
Cheers,
Frank
>
> Andy
>
>