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

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 >