myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Küppers (JIRA) <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-1834) suffix added to component id when including files
Date Wed, 12 Mar 2008 12:36:46 GMT

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

Christian Küppers commented on MYFACES-1834:
--------------------------------------------

I migrated to myfaces-1.2.2 and I have the same problems.
So, message tags don't find their component any more, when validation fails.

The method checkIfItIsInAnIterator() (javax.faces.webapp.UIComponentClassicTagBase) returns
true, because the key "javax.servlet.include.request_uri" is in the request-map (when validation
fails).

So I have removed the call to isIncludedOrForwarded() in checkIfItIsInAnIterator(), firstly.
And it seems to work for me.

    private void checkIfItIsInAnIterator(String jspId)
    {
        Set<String> previousJspIdsSet = getPreviousJspIdsSet();

        if (previousJspIdsSet.contains(jspId)) // || isIncludedOrForwarded())
        {
            isInAnIterator = true;
        }
        else
        {
            previousJspIdsSet.add(jspId);
            isInAnIterator = false;
        }
    }

Regards,
Christian

> suffix added to component id when including files
> -------------------------------------------------
>
>                 Key: MYFACES-1834
>                 URL: https://issues.apache.org/jira/browse/MYFACES-1834
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-252
>    Affects Versions: 1.2.2
>            Reporter: Simon Kitching
>            Priority: Minor
>
> In core 1.2 to 1.2.2, any use of jsp:include causes the ids of components in the included
file to have a random string appended to them.
> This results in some ugly ids. However more significantly, the id of a component is not
predictable even when an id attribute is explicitly assigned.
> In addition, this breaks the tomahawk forceId feature, because although the namespace
prefix is omitted the rest of the id changes making "forceId" useless.
> The cause is class UIComponentClassicTagBase, where checkIfItIsInAnIterator() returns
true if the current component is in an included or forwarded page. Later, the createUniqueId
method adds a suffix to the user-specified if member isInAnIterator is true.
> Unfortunately, documentation on why things are implemented as they are is lacking.
> Checking for iteration is needed to support
>   <c:forEach ..>
>    <h:inputText id="name"/>
>   </c:forEach>
> Checking for includedOrForwarded might be to allow:
>     <jsp:include page="subPage.jsp" />
>     <jsp:include page="subPage.jsp" />
> However this is a very rare usage; support for this should not hurt everyone.
> And Sun Mojarra does *not* mess with the ids like this...testing shows
> that the ids of components are the same regardless of whether they are
> inline or in an included file.
> Maybe the "isInIterator" check could look to see whether the *same file* is being included
twice, eg by keeping a list of the files included so far, and returning true only if the same
string is encountered twice? That would allow multiple inclusions, but not mess with ids for
a single inclusion.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message