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

[Andy Schwartz]

Hi Leonardo -

On 5/18/10 2:09 AM, Leonardo Uribe wrote:
> 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.

Ah, a topic near and dear to my heart. :-)

I proposed adding this API (and provided a patch implementing the 
solution) back in April 2009:

> 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 

However, this did not make it into the 2.0 spec.  I've mentioned a 
couple of times since that we really, really need to add this as soon as 
possible.   If we had any leeway for getting this into 2.0 rev A, I 
would say we should do so.  However, based on the description of 2.0 rev A:

> "2.0 Rev a" will include work that does not require any change in
>   behavior of the implementation (including any signature changes) or
>   TCK.  This work will be limited to spec edits.

It looks like this will need to wait for 2.1.


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


Here was the original rationale for adding this, from the thread 
"[180-TreeVisitor] Visit hints, UIData iteration" (December 2008):

> While looking at the UIData code base in preparation for implementing 
> UIData.visitTree(), I noticed that UIData's lifecycle methods perform 
> various phase-specific tasks.  For example, looking at 
> UIData.processDecodes(), I see that before processDecodes() iterates 
> over the children, it does some initialization work:
>
>>         setDataModel(null); // Re-evaluate even with server-side 
>> state saving
>>         if (null == saved || !keepSaved(context)) {
>>             //noinspection CollectionWithoutInitialCapacity
>>             saved = new HashMap<String, SavedState>(); // We don't 
>> need saved state here
>>         }
>
> The other UIData lifecycle methods do not do this, but perform other 
> minor initialization tasks.
>
> In the case of Ajax/partial processing, we will be using tree visitor 
> to execute partial lifecycle phases.  This makes me think that 
> UIData.visitTree() is going to need to be able to:
>
> 1. Know what the current phase is, so that it can to phase-specific 
> initialization.
> 2. Know whether or not the visit corresponds to the execution of a 
> lifecycle phase, as opposed to a generic tree visit that is invoked 
> from application logic (eg. from an action listener).
>
> #1 is easy enough - this information is available via 
> FacesContext.getCurrentPhaseId().
>
> I don't see how we can determine #2 without exposing this information 
> on the VisitContext - presumably as a new hint.
>
> In order to address this requirement, I would like to add a new hint 
> that indicates whether or not the visit is being performed as part of 
> lifecycle/phase execution.  By default this hint would be off.  When 
> we perform our partial traversals during Ajax request processing we 
> would turn this hint on.
>
> Unfortunately I cannot think of a good name for this hint.  Maybe 
> something like VisitHint.PROCESS_PHASE?  Suggestions for less awful 
> names (or other ways to solve this problem) would be appreciated!
>
> Andy 

Martin suggested "EXECUTE_LIFECYCLE" for this concept, and we rolled 
with that.

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

In the version of Mojarra that I happen to have sitting here (about a 
month old), UIData is looking for this hint.   However...  the 
PartialViewContext implementation is not actually setting the hint, so 
this is not actually being used at the moment.

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

Could you log a spec issue requesting that the doc be more explicit?

I will follow up on the Mojarra side to see that the PartialViewContext 
implementation is fixed.

Andy

>
> regards,
>
> Leonardo Uribe