1:09 a.m.
Hi
In myfaces implementation, I have found multiple locations where it is
necessary to traverse the "real" component tree. That means, it is necessary
to visit all components ignoring UIData "rows", or components that its
children renderer multiple components (for example t:dataList or ui:repeat).
It could be good to have a "standard" way to do that. I have the following
use cases where I can't use Visit Tree:
1. Publish PostAddToViewEvent
2. Add/remove components to the tree when partial state saving is used.
3. Add attached objects (like a custom client behavior that it is necessary
to attach on components with some conditions (t:autoScroll) ).
That problem has a side effect: PostRestoreStateEvent should be published
only for "real" component instances (the algorithm is restoring only one),
but in fact if you have a datatable it is published for all rows, that means
the same even is published for the same component over and over and over and
over and over.
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.
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. 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?. 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)?
regards,
Leonardo Uribe
5:22 a.m.
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
12:35 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] Visit Tree api cannot traverse "real" component tree
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(a)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
>
5128
days inactive
5129
days old
jsr-314-open-mirror@lists.jboss.org
2 comments
2 participants
participants (2)
-
Andy Schwartz -
Leonardo Uribe