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
