UIData needs review on a couple of fronts

Note that the following will most likely apply to 1.2 as well

From Martin Marinschek:
-----------------------------

a) if invokeOnComponent returns successfully for any of the facets,
invokeOnComponent should return with true - currently it doesn't (maybe there is
a reason for this I fail to see?)

b) I think that the NumberConversionException thrown from the current version of
this method is dangerous in the sense that if the client-id is not actually
valid (the component is not yet anymore in the table) but was a sub-component of
a naming-container in a facet (client-id
tableClientId:namContainerId:subCompId), the long client-id will trigger the
code to check if the component is in one of the rows and you will suddenly get a
number conversion exception popping up from the table. This is not the case with
other components and invokeOnComponent, and so should be done differently.
Instead, this NumberConversion exception has to be silently ignored - or a
better solution for this algorithm has to be found (I didn't find one in a
decent time-frame, however, and just ignored the NumberConversion exception in
my version).

As a side-note: could it be that you guys keep track of the state of children of
transient nodes? I seem to be running into this from time to time. Leonardo
mentioned this as an implementation difference to MyFaces to me, so maybe you
could check if this is the case (I don't think this would make sense - a
transient component would certainly mean every sub-component has to be transient
as well).

Start by locating UIData.invokeOnComponent and reviewing how facet success is reported and how client IDs are parsed. Check the handling of NumberConversionException and the behavior of children under transient nodes. Done means the intended behavior for both invokeOnComponent cases and transient-child state is established and covered by tests.

Written by the indexing model from the issue text.