On 29.05.2012, at 21:16, Andy Schwartz <andy.schwartz_at_oracle.com> wrote:
> 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 prefer the first option.
>
>> 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".
+1
>
>> ==<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 think that if both parties know what they are doing, we don't confuse them.
>> 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.
+1
>>> - 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.
+1
>> 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" />
+1
> Alternatively, we could have separate "attributes" tags for:
>
> 1. Populating the component attribute map.
> 2. Populating the passthru attribute map.
-1
>>> 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. :-)
Me too.
Cheers,
Frank
>>> - 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
>