Hey Imre -
Sorry about the late response...
On 5/24/12 10:27 AM, Imre Oßwald wrote:
> 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?
Right.
> (with the usual exclusion of id, rendered, etc.)?
Ugh. Forgot about the fact that we will still need to support
non-passthru, component-land attributes.
One option is that we special-case a small number of known component
attributes (id, rendered). The other option is that we require the use
of some explicit namespace for specifying component-level attributes, eg:
<div class="comp-div" data-foo="bar" c:rendered="#{el.to.rendered}"
jsfc="jsfc">
> 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)
Right - "elementName" is way better than "name".
> ==<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?
Interesting idea. I totally understand the appeal of moving towards a
page description model that is more web designer friendly. That's why I
like the idea of enhancing the jsfc approach to page authoring. Seems
that there is quite a bit more that we can do here.
However, once we move into the world of component tags (eg.
<h:inputText>), I am very nervous about blurring the lines between
attributes that live in component space vs. those that live in HTML
space. I don't necessarily think that life is going to be better for
either web designers or for JSF application developers if we smash all
of these together into a single namespace. In fact, I suspect that this
would have the potential to be confusing for both parties.
> 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.
>
My preference would be that we deal with this at the ResponseWriter
level and let the explicitly specified passthru value win.
>> - 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="#{...}"
Oh, yep. Much better.
> 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" />
Alternatively, we could have separate "attributes" tags for:
1. Populating the component attribute map.
2. Populating the passthru attribute map.
>> 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 :)
I think so too. :-)
>> - 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.)
I get it, though I would prefer that we start small - ie. support EL
binding out of the box and treat the use of JSON as the literal/inline
representation for collections as a separate issue. I am concerned that
if we don't approach this from a big picture perspective (eg. taking
dataTable and like cases into account), we'll end up making decisions
that we might regret later.
Andy
> Imre