[jsr-314-open] Spec-Issue https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408

[Andy Schwartz]

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
>