Hi
There are some additional problems to the same section, one related to
"class" attribute and other related to how "jsf" namespace is interpreted for
attributes. See:
https://issues.apache.org/jira/browse/MYFACES-3874
It seems it was fixed in Mojarra 2.2.4, and MyFaces 2.2.2 have fallen in the
same hole. Anyway it is worth to consider it because we need to change some
parts of the spec.
The user is trying this code:
<div jsf:id="mw-page-base" class="noprint"></div>
And in MyFaces it throws the following exception:
java.lang.IllegalArgumentException: Component property class is not writable
javax.faces.component._ComponentAttributesMap.setComponentProperty(_ComponentAttributesMap.java:709)
It is clear the fix to be applied is rename the "class" attribute to
"styleClass" like it has been done for long time in jsf components. But from
spec perspective, jsf:element tag should have styleClass attribute and the
renderer should render the attribute like it is done for other jsf components.
So the facelet taglibdoc of jsf:element and the renderkit javadoc of
javax.faces.passthrough.Element should be updated to include the "styleClass"
attribute.
But the user has reported another more troublesome combination:
<li jsf:class="toclevel-1 tocsection-2"/>
According to the spec it should not work. The javadoc of
javax.faces.view.facelets.TagDecorator
says this (already mentioned before):
"... If the current attribute's namespace is
http://xmlns.jcp.org/jsf,
convertedTagAttribute's qualified name must be the current attribute's local
name and convertedTagAttribute's namespace must be the empty string. This
will have the effect of setting the current attribute as a proper property
on the UIComponent instance represented by this markup. ..."
If the intention of jsf namespace is put the attribute into the attribute map,
why that syntax should work, unless the attribute has been explicitly declared
on jsf:element component. I tried also this combination:
<div jsf:style="noprint">
Hello World!
</div>
It works again, but it shouldn't. But it is clear why it is an obvious
combination. The same javadoc of TagDecorator detects any attribute with the
namespace "jsf" and if it is found the tag is binded to a jsf:element
component. The related line says this:
"... If one or more of the attributes of the tag argument are in the
http://xmlns.jcp.org/jsf namespace, obtain a reference to decoratedTag as
described in the following steps and iterate through the list of TagDecorator
instances as described in the preceding step ..."
In practice, it seems an attribute using "jsf" namespace should be added in
both normal attribute map and passthrough attribute map. I can't detect any
problem at the moment, because the logic in the default ResponseWriter keeps
track of the rendered attributes, and as long as no logical attributes are
copied, things will be fine. Here there is an example of the problem:
<div jsf:binding="#{boxBean.box1}">
Hello World!
</div>
In Mojarra this attribute is just ignored, so it doesn't work, but in
MyFaces it works, but if the attributes are copied in both maps, this one
will be a problem. So the algorithm should duplicate the attributes that
are not reserved like "id", "binding", "rendered" or "transient".
There are a couple of attributes that are implementation specific, but since
they are not declared in the markup, they do not have the chance to be
copied or overriden.
It is curious this syntax does not work:
<div pt:style="noprint">
Hello World!
</div>
The tag is not converted into a jsf:element, so the compiler sees it as
html markup.
I do not see any other choice than force the copy to the passthrough
attribute map of all attributes declared with jsf namespace. But I have
to warn about a side effect over the state. If the attributes are copied
twice, that means the state of that component is effectively doubled.
If PSS is properly implemented, it will not have a significant effect
over the state, because most of the time that part is not part of the
"delta" state of the component.
I'll fix MyFaces to reflect the reasoning proposed here, which follows the
behavior found in recent versions of Mojarra (discounting the bug found
in "binding" attribute).
regards,
Leonardo Uribe
2014-03-21 22:28 GMT+01:00 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Tue, 18 Mar 2014 21:37:58 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
> LU> Hi
>
> LU> Recently in MyFaces Core 2.2.1 it was found some inconsistencies
> LU> over the documentation done for HTML5 friendly markup (javadoc of
> LU> TagDecorator and JSF 2.2 section 10.1.4). There are basically 2
> LU> problems, that I will describe below. I have fixed them in MyFaces
> LU> Core 2.2.2.
>
>>>>>> On Thu, 20 Mar 2014 13:21:40 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>
> LU> Hi
> LU> Michael Kurz has created this issue to deal with this problem:
>
> LU> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1270
>
> LU> regards,
>
> LU> Leonardo Uribe
>
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 1 Work Days Til JavaLand 2014
> | 31 Work Days til JAX 2014