[jsr-314-open-mirror] [jsr-314-open] [806] Simplify PostRestoreStateEvent delivery requirements

[Andy Schwartz]

Gang -

I recently logged the following spec issue:

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

Short summary of the problem for those who don't want to read through 
the gory details:

The specification is currently a bit too specific about when 
PostRestoreStateEvents should be delivered.  The only requirement should 
be that these events are delivered after the view has been restored, but 
before we move out of the restore view phase.  For example, a reasonable 
implementation would be to deliver these events in the Lifecycle 
implementation, after the state manager has returned the restored view.  
However, the spec does not currently allow this - eg. the spec requires 
that UIViewRoot.processRestoreState() delivers these events.

Of course, UIViewRoot.processRestoreState isn't always called (only used 
for full state saving), which means that implementations end up having 
to duplicate this logic elsewhere, such as in whatever state manager is 
used for partial state saving.  This has further fallout for custom 
state managers - ie. custom state managers that do not call 
processRestoreState() must duplicate the event delivery logic yet again.

This is much more complicated than necessary.  My recommendation is that 
we simplify the requirements such that implementations are free to deal 
with PostRestoreStateEvent delivery in a saner way.  For example, 
implementations should be able to deliver these events once at the end 
of the restore view phase (and not be required to implement this logic 
in UIViewRoot.processRestoreState()).

I suspect that this small spec change will lead to simpler code in 
Mojarra (definitely) and MyFaces (probably, though I haven't looked at 
the code).

Does anyone have concerns about this proposal?

Martin, Leonardo -

Could you guys comment on whether this change would be acceptable to 
MyFaces?

Andy