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">
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.)
> 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.
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}"/>
Andy