Gang -
Need to bring up one of my favorite issues again. :-)
As described below, at the moment we have no way to suppress iteration
(over stamped rows, eg. in UIData) while performing a tree visit. This
is a problem for at least one existing case: PostRestoreStateEvent
delivery, where we only want to deliver the PostRestoreState once per
component, rather than once for each time that the component is stamped.
Mojarra's UIData implementation implements a workaround for the
PostRestoreStateEvent delivery case. Mojarra's UIData.visitTree()
implements checks the current phase and avoids iteration when the phase
== restore view.
However, this workaround is too limited. I need a solution for
suppressing iteration more generally, not just for restore view. For
example, in ADF Faces I need to perform an tree visit just before we
render the view. (This is related our recent discussion on resource
collection in the PostAddToViewEvent thread, which I am hoping we can
solve more generally 2.1.)
The correct solution is obvious: we need a new SKIP_ITERATION visit hint.
However, as we have discussed repeatedly, this is going to have wait
until 2.1.
Unfortunately, I desperately need a solution now.
Since my preferred solution (ie. a standard visit hint) doesn't seem to
be possible at the moment, I have reached the point where I am wondering
whether we could consider uglier, non-standard, temporary solutions.
For example, one option might be for the JSF implementations to
introduce a flag hanging off of the FacesContext attribute map that
would serve the same purpose as VisitHint.SKIP_ITERATION, at least until
we can get the standard solution in place for 2.1.
I realize that this is a terribly ugly thing to do, and I am reluctant
to ask that we even consider this. (Sorry!)
A fall back might be to introduce an equivalent framework-specific flag
that we could use for Trinidad/ADF Faces, though I was hoping for
something more generic - eg. something that would at least work with
UIData, but ideally with other 3rd party components as well. This would
require some coordination between MyFaces and Mojarra. Minimally, we
would need to agree to a common name for the flag.
Is this something that MyFaces/Mojarra folks would be open to?
Andy
On 4/17/09 7:51 PM, Andy Schwartz wrote:
Gang -
While reviewing this list with Ed earlier this week, Ed and I
discussed very small issue that is not mentioned in the list but which
we agreed to at least consider fixing for 2.0. The issue is related
to tree visiting and state saving. I believe that it is likely that
certain components may need to visit their children in a somewhat
different manner for state saving purposes - eg. a UIData may take
different steps when visiting children for state saving as opposed to
say, rendering an Ajax response. However, at the moment there is no
way for a visitTree() implementation to know that state saving is
being performed. visitTree() implementations do have access to the
current phase id via the FacesContext, but of course state saving does
not live in its own phase. In order to provide a way to inform
visitTree() implementations that state saving is being performed, I
proposed (to Ed) that we add a new visit hint.
Currently we've got the following visit hints:
> SKIP_UNRENDERED
> SKIP_TRANSIENT
> EXECUTE_LIFECYCLE
I would like to add this new hint:
> EXECUTE_STATE_SAVING
While thinking about visit hints and UIData again, I got back to
thinking about a use case that we had discussed in the past...
Currently there is no way to tell components which visit their
children multiple times (think UIData) not to bother performing
iteration - ie. to only visit each child one time. So, for example,
in the UIData case, there is no way to tell the UIData component to
not iterate over each row when visiting children. At one point I had
proposed a hint to provide control over this, but I never actually
added this to the API. After discussing this with my colleagues
internally here, we realized that we have at least one case where we
need this ability. So, while I am in the VisitHint enum, I would like
to also add the following new hint:
> SKIP_ITERATION
I have opened up the following spec issue to track these requirements:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=545
And have also uploaded a patch which adds both of these APIs (though
for the most part leaves the implementation alone).
If anyone has comments/questions about either of these, please let me
know.
Ed -
I realize that we did not discuss the SKIP_ITERATION proposal on our
call. Please let me know if you feel that it is inappropriate to add
this. I can upload a new patch.
Andy