[jira] [Commented] (MYFACES-3882) Page with template and stylesheet not rendered correctly

["Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/MYFACES-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967897#comment-13967897 ] 

Leonardo Uribe commented on MYFACES-3882:
-----------------------------------------

I have sended a mail to the EG users list describing the problem. It is clear the javadoc of TagDecorator is inconsistent and that Mojarra does not implement the javadoc, but the implementation they have is also inconvenient, so we cannot follow a broken javadoc and a ugly implementation at the same time. Instead, we should honor JSF 2.2 section 10.1.4 and create the implementation that works better in our point of view.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[jsr344-experts mirror] HTML5 friendly markup (fix inconsistencies and documentation review)

I think I have finally realized what went wrong in all this mess. In the spec
javadoc of TagDecorator it says this (only the relevant points):

"... Convert all the attributes of the argument tag as follows.  ..."

1. "... If the current attribute's namespace is http://xmlns.jcp.org/jsf, ..."

2. "... If the current attribute's namespace is empty or different from the
argument tag's namespace ..."

3. "... Otherwise, assume the current attribute's namespace is
http://xmlns.jcp.org/jsf/passthrough ..."

An inspection over the conditions written in the spec reveals that the
condition that suppose to be activated for the passthrough attribute is
never executed. I have checked all examples I have over this feature and it
is clear the "otherwise" condition does not work in reality as the spec says.

Suppose this example:

<div jsf:id="myBox" jsf:prop1="value" title="Hello World!" pt:lang="en">

</div>

jsf:id should call UIComponent.setId(), jsf:prop1 should store the attribute
in the normal component attribute map, pt:lang does not have any meaning so
it should never be used, but what happen with "title" attribute? We have been
discussing that, but it is clear that the intention is to put this attribute
in the passthrough attribute map. Which one is the condition that is supposed
to deal with this? Number 3, but what's happening is the algorithm always
catch the attribute in number 2 and number 3 is never executed.

I have checked the code and the attributes without namespace, and in fact
the attributes never receive a null namespace, instead they have an
empty string namespace. So, being strict with the spec javadoc, the
"otherwise" is executed only when the attribute has the same namespace
as the argument's tag namespace. Which are the options for the
argument's tag namespace? empty and http://www.w3.org/1999/xhtml. So,
in the condition 2 the "is empty" should be removed, because it doesn't
have sense.

In facelets, there is no namespaced attributes. In other words, all attributes
are processed no matter if they have namespace set or not. It is never used!
But in JSF 2.2 we have 2 special namespaces: jsf and passthrough. And now
these namespaces needs to be processed properly. But that means give facelets
compiler the ability to deal with namespaces.

But things get out of control when you have a line like this in the
javadoc of TagDecorator, in the condition 1:

"... 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 ..."

Remove the namespace is inconvenient. It is easier if the namespace is set
and with that information we let facelets compiler to deal with the
difference.

I think there are few people out there that really knows how facelets
algorithm works. But to clarify the implications of this problem, I'll describe
some details over that algorithm that becomes relevant in this case.

Facelets has a set of classes that helps to deal with apply the attributes
set in a tag into the target component. There is a method called:

protected MetaRuleset createMetaRuleset(java.lang.Class type)

where you can create a MetaRuleset, which have a set of MetaRule instances that
are applied in a ordered way for each attribute in the tag.

What is a passthrough attribute? it is an special type of attribute that is
just added to the passthrough attribute map. What is a jsf attribute? a normal
attribute that needs to be passed through the existing rules in MetaRuleset.
Who should be responsible to decide if the attribute should be processed as
a normal attribute or as a passthrough attribute? MetaRuleset. The right way
to do it is update MetaRuleset implementation with the necessary logic
to deal with passthrough attributes. An strategy that relies in a default
TagDecorator only will not work properly.

Where do the copy of attributes in Mojarra happens? Based on the previous
argumentation and the tests done, I would guess it happens because the
attributes are effectively processed twice, as a passthrough attribute and
as a normal attribute, because as I said before, facelets never ever
considered namespaced attributes, even if they let the blank spots the
logic to differentiate them is not there. Why? because if you need to
process a namespaced attribute you add a MetaRule, and the last one added
is the first one to be applied.

In my personal opinion, and based on the previous argumentation, this is
what I think:

1. The spec javadoc of TagDecorator is inconsistent and needs to be fixed.
2. Mojarra does not implements what the spec javadoc of TagDecorator says
about, but its implementations follows the spec intention, described in
JSF 2.2 section 10.1.4.
3. The details on the javadoc of TagDecorator that are too implementation
specific, and it does not follow the spec intention, so there is no other
choice that forget about that part, which is definitively broken and
honor JSF 2.2 section 10.1.4, which is consistent.

I'll try to fix MyFaces to resemble the spec as close as possible, without fall
in the bugs and inconsistencies we have discussed here.


> Page with template and stylesheet not rendered correctly
> --------------------------------------------------------
>
>                 Key: MYFACES-3882
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3882
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 2.2.3
>            Reporter: Michael Kurz
>         Attachments: MYFACES-3882-test.zip
>
>
> With the artefacts for version 2.2.3 provided by Leo for the vote, I have severe problems with one of my applications. It seems, that there is some error showing a page with a template.
> First problem is, that a stylesheet linked in the template is not rendered. Therefore the page looks completely different in the browser. With 2.2.1 and 2.2.2 it works like expected.
> Additionally, two messages with the label "Component with no name and no body content, so nothing rendered." are shown by h:messages.



--
This message was sent by Atlassian JIRA
(v6.2#6252)