[
https://issues.apache.org/jira/browse/MYFACES-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789002#action_12789002
]
Leonardo Uribe commented on MYFACES-1834:
-----------------------------------------
Testing some stuff for myfaces core 2.0, I note one case that makes the
previous solution fails. It is a very strange case and very difficult to
reproduce, because many details should coincide, but it was the key to resolve
this issue once for all. The example that reproduce it is
myfaces-example-simple/css.jsf
Everything starts with f:view tag. This one is not included when we check for
duplicate id in UIComponentClassicTagBase (because is the "parent tag" and the
algorithm check for duplicate ids on child), so it is possible to assign to a
component in a jsp:include the id of the UIViewRoot instance and cause a
duplicate id exception when the view is saved.
Since generated ids are only rendered when a component requires it by some
reason, in normal case this one is very hard to detect (note jsp ids are set
for every tag so if the id assigned to UIViewRoot is the same that other non
component jsp tag the error does not arise). Unfortunately, users found this
one but it was very complicated to understand, because no visible evidence
could be sent without do an full step by step.
To make things worse, there was some problems with the id checkForDuplicates
solved in MYFACES-1825 that were solved in the same time this one was checked.
By coincidence, it was checked the documentation of setJspId() method. It says
the following:
"....Defined on JspIdConsumer. This method is called by the container before
doStartTag(). The argument is guaranteed to be unique within the page.
IMPLEMENTATION NOTE: This method will detect where we are in an include and
assign a unique ID for each include in a particular 'logical page'. This allows
us to avoid possible duplicate ID situations for included pages that have
components without explicit IDs......."
Originally, the code form UIComponentTag in myfaces core 1.1 was "refactored"
to fit in UIComponentClassicTagBase, so this part was just skipped. In other
words it says this is the place where the "pc" suffix is added. Just number the
"pageContext", the first one does not have any but the remaining the suffix
pc2, pc3..... should be added to all components.
This note has another effect: jsp:include takes precedence over c:forEach, so
if a jsp:include is used inside a c:forEach, the "pc" or "page counter" is
added and since no duplicates are detected, no j_id_1 or something similar is
prefixed.
If the user set a custom id to a component inside jsp:include inside c:forEach,
a duplicate id exception is thrown, again because jsp:include takes precedence
over c:forEach.
At last we can close this issue.
> 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.
