[jsr-314-open-mirror] [jsr-314-open] Visit Tree api cannot traverse "real" component tree

Leonardo Uribe lu4242 at gmail.com
Tue May 18 02:09:04 EDT 2010


Hi

In myfaces implementation, I have found multiple locations where it is
necessary to traverse the "real" component tree. That means, it is necessary
to visit all components ignoring UIData "rows", or components that its
children renderer multiple components (for example t:dataList or ui:repeat).


It could be good to have a "standard" way to do that. I have the following
use cases where I can't use Visit Tree:

1. Publish PostAddToViewEvent
2. Add/remove components to the tree when partial state saving is used.
3. Add attached objects (like a custom client behavior that it is necessary
to attach on components with some conditions (t:autoScroll) ).

That problem has a side effect: PostRestoreStateEvent should be published
only for "real" component instances (the algorithm is restoring only one),
but in fact if you have a datatable it is published for all rows, that means
the same even is published for the same component over and over and over and
over and over.

It could be good to have a hint that could be called
VisitHint.VISIT_REAL_COMPONENTS or something like that that visit only real
components.

In othe side, looking the documentation there is a hint called
VisitHint.EXECUTE_LIFECYCLE that says the following:

"Hint that indicates that the visit is being performed as part of lifecycle
phase execution and as such phase-specific actions (initialization) may be
taken."

I understand why VisitHint.SKIP_TRANSIENT and VisitHint.SKIP_UNRENDERED, but
looking the javadoc I couldn't find when, how or why that hint should be
set. At this time, myfaces just ignore it, but if it is used, there should
be some documentation on UIComponent.visitTree or UIData.visitTree. Maybe
I'm wrong about that, and if myfaces don't use it really there is not
problem, but the point is: Is mojarra really implementing the algorithm that
says the javadoc?. It could be good if someone could check this algorithm
against javadoc, because really it is very suspicious.

Should I open an issue for these ones (one for each problem)?

regards,

Leonardo Uribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100518/312e8740/attachment-0002.html 


More information about the jsr-314-open-mirror mailing list