myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <>
Subject [jira] Commented: (MYFACES-1834) suffix added to component id when including files
Date Wed, 18 Jun 2008 22:19:45 GMT


Leonardo Uribe commented on MYFACES-1834:

After thinking this issue what mojarra does have sense. Use another prefix tracks the problem
of what happens when someone uses <jsp:include> and <c:forEach> together

The most sane for everybody is do what jsf ri does. In fact, what jsf ri does goes according
to the spec:

"....Several mechanisms (including the <jsp:include> standard action, the JSTL
<c:import> custom action when referencing a resource in the same webapp, and a call
to RequestDispatcher.include() for a resource in the same webapp) perform a
runtime dynamic inclusion of the results of including the response content of the
requested page resource in place of the include action. Any JSF components created by
execution of JSF component custom actions in the included resource will be grafted onto
the component tree, just as if the source text of the included page had appeared in the
calling page at the position of the include action..."

The behavior shown in jsf ri seems to be is the most sane so I'll try to implement it.
 (No matter what happens with generated ids, the important is that when using jsp:include
adds a different prefix).

> suffix added to component id when including files
> -------------------------------------------------
>                 Key: MYFACES-1834
>                 URL:
>             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.

View raw message