[ https://issues.apache.org/jira/browse/MYFACES-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585251#action_12585251 ]
Brian Kates commented on MYFACES-1834: -------------------------------------- I also disagree with the priority on this issue. This is a major show stopper for anyone that uses Tiles. > 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.