On the pass through behavior, we need to understand that any accidental
propagation of what was a server-only attribute to the client can be a
serious security breach.
I am not a fan of the init param approach because:
1) It assumes that the application author knows the behavior of every
single extra attribute in the application
2) Markup moved from an application with one value of the init param to
another will magically have different behavior
-- Blake Sullivan
On 5/23/12 11:00 AM, Frank Caputo wrote:
> On 23.05.2012, at 05:11, Phil Webb<pwebb_at_vmware.com> wrote:
>
>> Could the idea of pass-though attributes also apply to components?
> I supposed it to work for all 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"/>
> I've chosen h:panelGroup because HTML developers are used to<div jsfc="h:panelGroup" id="foo">...</div>. But<ul jsfc="d:ul" id="foo">...</div> would also be ok (maybe a little bit redundant).
>
>> Anything prefixed with the 'd:' schema gets created as a dynamic pass-though component. 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.
> Using jsfc let's IDEs do their job fine, because they can validate if HTML is correct and if it is also a correct facelet.
>
>> 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.
> I understand the point (I also do funny things with additional attributes). Maybe it would be a good idea to have yet another init-param to change the behavior.
>
>
> Cheers,
> Frank
>
>
>> Cheers,
>> Phil.
>>
>>
>> ----- Original Message -----
>>> From: "Brian Leathem"<bleathem_at_gmail.com>
>>> To: jsr344-experts_at_javaserverfaces-spec-public.java.net
>>> Cc: "Frank Caputo"<frank_at_frankcaputo.de>
>>> Sent: Tuesday, May 22, 2012 2:29:27 PM
>>> Subject: [jsr344-experts] Re: [1089-HTML5-data-*attributes] PROPOSAL
>>>
>>> On 12-05-22 01:39 PM, Frank Caputo wrote:
>>>> Hi EG,
>>>>
>>>> I had similar thoughts about HTML5.
>>>>
>>>> HTML5 is DTD-less and supposed to change quickly. To allow this
>>>> agility, we should have 2 things:
>>>>
>>>> 1) render through unknown attributes
>>> Agreed! This would by far provide the simplest markup, with the
>>> easiest
>>> "buy-in" from those developers familiar with HTML 5. Give it a few
>>> more
>>> years, and this means everyone.
>>>
>>>> 2) have a generic dynamic element
>>>>
>>>> Explanation:
>>>>
>>>> 1) All attributes not handled by a component should be simply
>>>> rendered
>>>> out as they are. Eg. h:inputText doesn't know the attribute
>>>> placeholder.
>>>>
>>>> <h:inputText value="#{foo.bar}" placeholder="foo"/> would be
>>>> rendered
>>>> as<input type="text" value="" placeholder="foo"/>
>>>>
>>>> This way new attributes in HTML5 are no longer a problem (this
>>>> would
>>>> also be fine for all those data-xxx attributes ;-))
>>>>
>>>> If the value of an unknown attribute is null or "", don't render
>>>> it.
>>>>
>>>> Maybe we could override attributes. Eg. h:inputText doesn't have
>>>> the
>>>> attribute type, but the renderer renders it.
>>>>
>>>> <h:inputText value="#{foo.bar}" type="email"/> would be rendered as
>>>> <input type="email" value=""/> because the unknown attribute
>>>> overrides it.
>>>>
>>>> The type attribute is just a hint for the client (eg. to change the
>>>> keyboard layout) while it doesn't change anything on the server.
>>>>
>>>> UIComponentBase should provide a Map of all unknown attributes to
>>>> the
>>>> renderer.
>>> The problem with this being that facelet files are not DTD-less
>>> (shema-less), and so this would be a more complex solution. IMO
>>> however, it would be an effort worth pursuing, as the arbitrary
>>> attribute support would be intrinsic to JSF, and not "bolted on".
>>>
>>>> 2) A UIComponent which could represent any HTML tag would be very
>>>> helpful, eg. if one wants to render anything else but a div or span
>>>> conditionally or have it in the render list of a partial response.
>>>> We
>>>> should add this functionality to h:panelGroup. We could either
>>>> deprecate the layout attribute and add a new one for the tag name
>>>> or
>>>> enhance it to simply hold the tag name.
>>>>
>>>> <h:panelGroup layout="ul" type="disc" id="foo"/> would be rendered
>>>> as
>>>> <ul type="disc" id="foo"></ul> if we would also have 1).
>>>>
>>>> We could also enhance the facelet parser to let us have tags like
>>>> <ul
>>>> type="disc" id="foo" jsfc="h:panelGroup"></ul> which handles
>>>> jsfc="h:panelGroup" specially and converts it to<h:panelGroup
>>>> layout="ul" type="disc" id="foo"/> using the tag name for the
>>>> attribute layout.
>>> An interesting suggestion, worthy of it's own issue (it if doesn't
>>> already have one.
>>>
>>>> I think, that both features provide pretty much HTML5
>>>> functionality,
>>>> because most of them are client side. The only one making my head
>>>> aching is the form attribute of the input elements
>>>> (http://www.html5rocks.com/en/tutorials/forms/html5forms/#toc-inputs-attributes-attributes).
>>>>
>>>> Another benefit is the ability to support browser specific tags and
>>>> attributes which makes sense in intranet applications.
>>>>
>>>> It would also increase the acceptance for HTML developers, who are
>>>> often unhappy with not letting them do what they want when they
>>>> must
>>>> use JSF.
>>>>
>>>> Frank
>>> Brian
>>>