Hi Leonardo,
sorry for answering that late. I investigated the code and the spec and there is definitely an error in the spec:
> * If the current attribute's namespace is empty or different from the
> argument tag's namespace, let the current attribute be
> convertedTagAttribute. This will have the effect of setting the current
> attribute as an attribute on the attributes map of the UIComponent
> instance represented by this markup.
Your proposed change reflects the current (intended) behavior. Though it can be achieved by changing just 2 words (bold):
* If the current attribute's namespace is not empty and different from the
argument tag's namespace, let the current attribute be
convertedTagAttribute. This will have the effect of setting the current
attribute as an attribute on the attributes map of the UIComponent
instance represented by this markup.
Am 14.04.2014 um 17:44 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
> <div jsf:id="box6" onclick="alert('hello')">
> <f:ajax event="click" render="box5"/>
> MYBOX6
> </div>
>
> will not work, but this one:
>
> <div jsf:id="box6" jsf:onclick="alert('hello')">
> <f:ajax event="click" render="box5"/>
> MYBOX6
> </div>
>
> will do. The reason is JSF 2.2 spec section 10.1.4 says this:
>
> "... To allow further flexibility, the existing Facelets TagDecorator
> mechanism allows complete control of the mapping process ..."
>
> Which means in the previous case, the onclick declaration always overrides
> the Renderer. It is not very intuitive, because the user could not want
> that or perceive this as a bug, but in the other side the fix is trivial
> and easy to understand.
I like this simple rule: Empty namespace always makes it into the passthrough attributes and these always take precedence.
> About this example:
>
> <h:panelGroup id="box5">
> <div jsf:style="noprint">
> MYBOX5
> </div>
> </h:panelGroup>
>
> There is no other choice than to include the style properties (style and
> styleClass) to jsf:element component and make the renderer render them.
> That is to avoid compatibility problems later.
Yes, we should add style and styleClass.
Ciao Frank