The problem is that the UIViewRoot in older versions of MyFaces doesn't guarantee that the Id is unique across calls-- which breaks the contract of the method. Facelets doesn't need to change anything.
Facelets doesn't 'cache' anything. It creates the tree and the state saving method of the JSF implementation saves the component tree for processing on succeeding requests (less the unique id counter on the viewroot). If the UIViewRoot is fixed, then it should NEVER hand out the same ids-- so in a sense, the problem you are seeing is created by MyFaces itself. >Okay, I've been digging deep into MyFaces SVN and facelets 1.0.14 >source code to try to find the issue of duplicate IDs. It looks like >it is a facelets bug after all. > >What I've been able to find out so far: > >MyFaces creates a view with a bunch of facelets tags (defines, >includes, compositions, etc.). This creates several facelets objects >that represent cached "views" for defines and etc. > >The particular problem seems to be happening with DecorateHandler.java >and the classes it is using. (I haven't pinpointed the exact problem >as I am having stability issues debugging JBoss in eclipse, so am >hunting and pecking through source in VIM). > >Facelets is caching the decorated view. So, when I hit the first page >it is fine. At that point, facelets is caching the components that >made up the view for my decorated page. > >Then, after navigation, and a new view is created, facelets seems to >be re-hydrating this cached copy of the decorated view for the new >view. This cache copy of components contains components with >auto-generated IDs. > >The MyFaces UIViewRoot knows nothing about these cached components and >therefore does not check any components in the view for existence of >auto-generated IDs. Therefore when facelets adds the cached version of >the component to the tree, it is not reserving unique IDs. > >As a result, the first component that was cached in the decorated file >with an auto-generated ID will clash with any components in the new >view given that very same auto -generated ID. > >The fix? Well this is up to you Jacob I guess, unless MyFaces wants to >help with this. > >1) In facelets, (during the mark & sweep?), when a cached component >hierarchy is being used, check all IDs in the component tree with >naming matching the regular expression "^_id\d+" and assign a new ID. > >Example: >if (regex.matcher(component.getId()).matches())) > component.setId( /* get a new ID from the view */); > >2) In UIViewRoot of MyFaces, when components are added to the tree, or >when assigning a new ID, check the existing components in the tree to >make sure the auto generated ID has not already been assigned to a >component (don't assume UIViewRoot is the only source of "_id#" style >IDs) > >3) Something else. > >What do you think? >-Andrew > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >
