[jsr-314-open-mirror] [jsr-314-open] Tree visit hints [Was: ADMIN: Final list of issues for JSF 2.0 and actions for each]

[Andy Schwartz]

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
>
>