Re: [jsr-314-open] Spec-Issue https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408
Gang -
I wanted to check up on this issue as it impacts our ability to leverage
partial state saving (which we very much want to use). I see that this
issue is now being tracked here:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313
And it looks like there are plans to fix this in Mojarra 2.0.3, but just
wanted to make sure that there weren't any concerns about the potential
fixes.
My thinking is that we would go with Martin's proposed fix #1:
1) (preferred) do as Facelets did before: treat the second
merry-go-round (application of tag-handlers) slightly different. Just
deal with new components (call mark initial state) and deleted
components (let them silently fall under the table, don't treat them
as dynamically removed components), and don't call onComponentCreated,
but onComponentPopulated if the component has been found. The
tag-handlers already expect this behaviour.
One reason why I was thinking we would go with this approach is because
this mirrors the behavior provided by the full state saving case. It
doesn't seem like our decision to re-execute handlers after invoke
application should be influenced by our choice of full or partial state
saving. In both cases we need to give handlers a chance to operate on
the previously restored view.
Regarding one concern that Ryan raised in 1313:
Component resoures. When the facelet handlers are re-applied during
render response, ComponentSupport.findChildByTagId() will never find
the existing component resource as it was relocated to the UIViewRoot
so Facelets considers the component as new each time.
Perhaps I am missing something here, but doesn't this issue exist in the
full state saving case as well? Don't we end up with the same component
tree after the view is restored, regardless of whether we restore by
building + applying deltas (partial) or solely from state (full)? I
always thought that the goal was that these two techniques for restoring
the view should end up restoring the component tree back to the same
state (ie. the state that it was left in on the previous request).
Andy
Martin Marinschek wrote:
Hi,
I just ran into a new issue with 2.0: a condition-change in the test
attribute of a c:if in invoke-application doesn't lead to a changed
component tree, as the tag-handlers are not reevaluated before render
response.
In Facelets old, they were evaluated --> therefore, this is a
backwards compatibility issue.
That now is really a show-stopper for us with regards to 2.0 - the
first real one we encounter.
regards,
Martin