Tree2 + Immediate Links

["Hagen, Nicholas" <NH...@trane.com>]

I have a simple tree2 via:

<h:form id="form" ...>
	...
	<h:commandLink action="success" value="Test" immediate="true" />
	<t:tree2 id="test" var="node" value="#{Bean.model}"
clientSideToggle="false">
    		<f:facet name="data">
    			<h:outputText value="${node.description}" />
    		</f:facet>
    	</t:tree2>
	...
</h:form>

When first accessed, the page works correctly and the generated html shows:

	<span id="form:test" ...>....</span>

However, if I click on the "Test" link that has "immediate" set to true,
using no navigation rules so that the page just gets redisplayed, then I end
up with an end result page with html:

	<span id="form:test:0" ...>...</span>

Looking into the code it appears that the ":0" is appended during
UIDataTree.getClientId() because the nodeId is not null.  Normally, the tree
is processed by calling the processDecodes, then processValidators,
processUpdates, etc.  At the end of processValidators and processUpdates,
setNodeId(null) is called to reset the node id.  Then, when encodeChidren is
called on the renderer, the nodeId is null so that the clientId is correct.
When "immediate" is set to true, then processValidators and processUpdates
do not get called.  Thus, the last decoded child (from processDecodes) is
set as the node id, because processDecodes does not call setNodeId(null) nor
does encodeBegin().  I looked at the implementation of HtmlDataTable and it
appears that in its encodeBegin function that it calls setRowIndex(-1) to
ensure the row is reset prior to building the table.  I am wondering if this
same behavior needs to be done in UIDataTree so that the node id is reset to
null prior to rendering the tree.  Also, should processDecodes call
setNodeId(null) at the end of its processing similar to processValidators
and processUpdates?

If this is a bug, let me know and I will write it up; otherwise, let me know
if something else needs to happen when using immediate links with a tree to
ensure the "id" is properly set.

Thanks,
Nick