myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "simon.kitching@chello.at" <simon.kitch...@chello.at>
Subject core1.2: handling of component ids in included files
Date Mon, 10 Mar 2008 15:00:05 GMT
Hi All (and particularly Bruno):

In core 1.2, class UIComponentClassicTagBase messes with the "id" field
of components if they "are in an iterator", adding a (clumsy) unique
suffix string.

And for some reason it defines "in an interator" as any kind of include
or forward.

So doing something like this:

== mainpage.jsp
<f:view>
    <jsp:include page="subPage.jsp" />
</f:view>
== subPage.jsp
<h:form id="foo"/>

causes the form component to have an id of "fooj_id_2" or similar.

This behaviour just looks weird to me. Why mess with ids just because
the file being processed is included or forwarded-to?
Does anyone have any idea what the purpose of this is?

In particular, this breaks Tomahawk forceId on myfaces1.2 when the
component with forceId is in an included file. But it looks really ugly
in normal cases too.

I understand that ids need to be messed with in order to support
components being "in an interator":
  <c:forEach ..>
   <h:inputText id="name"/>
  </c:forEach>

But why check for includedOrForwarded too? Is this include-handling
perhaps to allow
    <jsp:include page="subPage.jsp" />
    <jsp:include page="subPage.jsp" />
to work correctly? If so, then currently users are paying a very high
price (unstable ids when refactoring into included files) for a feature
that very few will need (multiple includes of the same file).

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.



This code was committed by baranda in commit 462531, ie this class has
behaved like this from very early times.
Bruno, what was the reason you added this?

Regards,
Simon


Mime
View raw message