Honestly... I don't remember, but I think I got this idea from somewhere
else (otherwise I would remember). Writing the UIComponentClassicTagBase
class was the most complicate part for me and one of the first things I did
for the 1.2 implementation. Probably the generate IDs ensure that the ids do
not clash, but I don't remember what does the spec says (if anything) about
it. However, if mojarra does not use such system we should probably be
compatible with them in that aspect.

See you this week! ;)

Bruno

On 10/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> 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
>
>

Reply via email to