Hi,
Andy Schwartz wrote:
> Gang -
>
....
> In any case, if we start by adding:
>
> - jsfc="true" (or jsfc="h:element") for pass-through elements
I was just about to propose that too, so
+1
I guess "pass-through" elements, means, that apart from the element name, also all attributes would be passed through 1:1? (with the usual exclusion of id, rendered, etc.)?
I'd like to see this as short as possible, so if we go with "element", maybe h:elem is sufficient, or eventually (while not that nice) h:tag, or just alias h:tag to h:element
<h:element elementName="ul" .... > (We probably do not want the attribute to be "name", as name is a common attribute for HTML elements)
== <ul jsfc="h:tag" >
== <ul jsfc="jsfc"> (if we should ever be able to just use <ul jsfc> then this would be the usual approach for SGML vs. XML)
> - p:foo="bar" for pass-through attributes on existing (rendering) component tags.
+1, this is a nice and probably the least intrusive approach.
Maybe we could make p: "include" h: so one could write
<p:inputText dropzone="link" />
so that the attributes do not have to be prefixed for template authors, that "know what they do", which would then result in "unused" attributes being passed-throu?
I am not sure about that, but on "normal" components, we will have to decide what we do if someone writes: p:knownAttributeToTheComponent="" vs. knownAttributeToTheComponent="" anyway.
> - passThruAttributes="#{foo.mapOfPassThroughAttributes}"
-1 I don't like this one, as it introduces a new attributeName to nearly all components in the spec, if at all: p:attributes="#{...}"
I think we should still have <f:attributes> (anyway as I want it for composite components ;) ) perhaps with an passthrough attribute <f:attributes value="#{foo.mapOfPassThroughAttributes" passthrough="passthrough" />
>
> We'll have come a long way towards improving our HTML5 story for JSF 2.2.
Right!
....
>
> Additionally, to address Paul's use case (arbitrary # of possibly dynamically determined bonus attributes), we could add one new non-namespaced attribute:
>
>> <h:commandButton passThruAttributes="#{foo.bonusAttrs}"/>
>
> This minimally allows EL-binding to a Map<String>.
>
> I think we'll need to argue more about whether we should:
>
> - Support JSON as a literal (inline) representation. And/or...
With the possibility to add as many attributes as you want with p:*, I don't see the benefit in allowing JSON as literal (inline) anymore. IMHO there is no difference for the template author between:
<h:whatever p:attributes="{'data':{'foo':'bar','fuu':'ber'}}" />
and
<h:whatever p:data-foo="bar" p:data-fuu="ber" />
apart from, that the later one is a lot easier to read and write :)
> - Support JSON as an accepted type in the EL-binding case.
>
In my opinion EL-binding should be limited to Map<String,Object>
(if we get f:attributes (and I hope so) we may still consider allowing JSON to be inlined as element text, as we could then for dataTables etc.)
Imre