You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2008/08/04 17:34:46 UTC
[jira] Commented: (MYFACES-1834) suffix added to component id when
including files
[ https://issues.apache.org/jira/browse/MYFACES-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619549#action_12619549 ]
Leonardo Uribe commented on MYFACES-1834:
-----------------------------------------
The solution applied on trunk (1.2.4-SNAPSHOT) is the most simple possible solution.
But the solution presented maybe does not play well when it is used combinations of jsp:include AND c:forEach components (the problem is how generate c:forEach inside a jsp:include page and vice versa). Really, this is a very, very, very rare case, since actually many people are using myfaces core + facelets, or avoid combinations of old jsp tags and use jsf components when it is possible.
So I cannot close this issue because in fact exists one failure case (combination of c:forEach and jsp:include), but the simple solution was applied on trunk to allow users use jsp:include (tiles support) without problem.
> 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.