Ok, thanks Bruno. I'll create a jira issue for this, then try to find some time soon to look into the related specs. At the least we need to document this, but hopefully can tidy up the id suffixes too. It's a little embarrasing that tomahawk forceId works on Sun but not on myfaces :-)
See you wednesday.. Cheers, Simon Bruno Aranda schrieb: > 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] > <mailto:[EMAIL PROTECTED]>* <[EMAIL PROTECTED] > <mailto:[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 > >
