Hey Martin -
Martin Marinschek wrote On 4/19/2009 12:18 AM ET:
Hi Andy,
the execute state-saving part absolutely makes sense to me.
Great.
For the
other thing, we said that people could just walk the component tree as
they had done it before - namely calling getFacetsAndChildren(),
a.s.o.
Ah, that's right. I was trying to remember where we left off with that. :-)
So the deal is that the tree visitor approach offers a couple of
benefits over getFacetsAndChildren():
1. It supports implicit short-circuiting - eg. NamingContainers can
short-circuit when performing a partial visit in the case where there
are no ids to visit in the NamingContainer subtree.
2. It allows component implementations to establish context (eg. set up
EL variables, or state that might influence client id generation) while
visiting the component's subtree.
I didn't realize it when we last discussed this issue, but in ADF Faces
we have cases (well, at least one case that we have identified so far)
where we very much want to take advantage of both of the above features
of tree visiting, but where we just want to visit each child (eg. each
column in a UIData) one time - no need to iterate over each row. I
wouldn't be surprised to see other cases arise, so would like to get
this hint into the tree visitor mechanism
But you might be right that this is too tedious to do if you can
just
use the tree-walker instead. So I am not against this second hint
either.
Cool. Thanks for reviewing this Martin!
Andy
regards,
Martin