Fixing JSF state saving: a progress report
The very latest and greatest Facelets source code has a
facelets.BUILD_BEFORE_RESTOREinitialization parameter. When turned on, it changes
ViewHandler.restoreView()to build the view before asking the StateManager for help.
And the latest ADF Faces code adds a new
markInitialState()method to our components - which calls through to
FacesBean.markInitialState(). When our MyFaces svn repository is set up, you'll be able to see this code too...
And the results? Well, one test case with a fairly large page dropped from nearly 10K of client-side state to only 600 bytes. That's more than a 90% reduction in saved state! (Presumably, CPU usage is way down, but I haven't measured that yet.)
There's still potential improvements: I could get that 600 bytes down further by overriding the state saving in UIViewRoot. Also, Jacob's suggestion to use a flat Map instead of a hierarchy would also help - currently, if one component deep in the hierarchy needs to store state, we build up a large hierarchy of mostly null Object arrays. This isn't especially expensive, but it is avoidable.
A footnote: Mike Youngstrom cogently noted in a comment to my last post that a delta approach to state saving would let us make UIData both simpler and more generic - instead of handcoding a specific set of properties to save on certain types of child components, just run state saving. Absolutely, Mike! I haven't prototyped this on our UIXTable component (which doesn't extend UIData, FWIW), but that's a great thing to try.