Apologies, Andy is correct, <d:ui> should be <d:ul>.
> 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
>
>
>