[Trinidad] tr:tree issue while forcing a component to be re-created

[Renzo Tomaselli <re...@tecnotp.it>]

Hi, while using Trinidad+Facelets I adopted a simple technique to 
override the limit of any component ID being compile-time bound.
At the same time, I overcome similar static behavior in Facelets c:if, 
c:forEach and alike.
The tecnique concerns - for a given component to be refreshed - killing 
all children of the component parent, which is achieved by the binding 
attribute:

            List<UIComponent> children = parent.getChildren();
            if (children != null) children.clear();

this way Facelets - at rendering time during the "apply" compilation 
chain - recreates the component asking all its properties again to the bean.
It works well, providing a fully dynamic environment - however I'm 
meeting some problems with Trinidad collections - such as tr:tree.

Since the component is bound to the bean - I have the binding method 
called twice, during any PPR request where I perform the above cleanup: 
once while restoring (old component) and once while rendering (new one). 
Cleanup occurs in between, because of some action processing.
Thus the second time I migrate the component status the the new 
component by calling:

                newc. setDisclosedRowKeys(oldc.getDisclosedRowKeys());
                newc. setSelectedRowKeys(oldc.getSelectedRowKeys());
                newc. setFocusRowKey(oldc.getFocusRowKey());
                newc. setClientRowKey(oldc.getClientRowKey());

However this seems not enough. Any next attempt to expand/collapse a 
tree node fails within UIXCollection.setClientRowKey() 
("CANNOT_FIND_ROWKEY") since _currencyCache does not contain any such 
key (being empty for the new component).
The second attempt succeeds.

It appears that such cache is expected to be valid across requests, so 
the question is: what else do I need to migrate from old component to 
the new one, to avoid this error ?
Thanks,

-- Renzo