Fixing JSF state saving: a progress report

I've implemented the first version of an improved JSF state saving architecture, essentially what I talked about in my last post.

The very latest and greatest Facelets source code has a facelets.BUILD_BEFORE_RESTORE initialization 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.