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

[Leonardo Uribe]

Hi Andy

Ok I created this one for the documentation of UIData.VisitTree:

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=803

best regards,

Leonardo Uribe

2010/5/18 Andy Schwartz <andy.schwartz at oracle.com>

> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100519/f153f374/attachment-0002.html