How we're going to fix JSF state saving

State is not bad. Statelesness is not good. State is your friend. But like a bad friend, State can sometimes hang around the house, eating your Mitchell's ice cream and drinking your Amarula 'til he gets fat and lazy, turns your house into a pig sty, and makes you wonder why you ever were friends with him in the first place.

JSF state is kind of like that. As I've said in a previous post, JSF state saving is way too hefty and saves far too much that doesn't need to be saved in the first place. So, here's my 5 step plan for fixing that.

Step 1

1. Use Facelets.

Step 2

2. Enhance the ADF Faces FacesBean API to support a "delta" mode - call a new markInitialState() method on it, and its saveState() implementation only saves all the changes made since markInitialState(). And if there's no changes, just return null. (You can't easily do this without FacesBean; see my earlier post on the subject.)

Step 3

3. Update the ADF Faces Facelets TagHandlers to call markInitialState() after creating the components.

Step 4

4. Implement Jacob Hookom's idea to save the tree of component state in a Map, not a gigantic Object array hierarchy.

Step 5

5. Rewrite the Facelets restoreView() implementation to recreate the tree from scratch in its original state, then call restoreState() on each component from the Map we built up in step 4.

And done. You don't need to save the tree structure anymore - Facelets is handling that by recreating the tree from its cached TagHandlers. And since most components don't actually change - unless you explicitly set properties on them - most components don't have to save any state.

(P.S.: there's some trickiness here that I'm ignoring: if you add components dynamically to the hierarchy, you do have to save their state and structure, since it's not present in the page. That's one reason why I strongly recommend making all dynamically created components transient if you have any choice in the matter, but that's a subject for another post.)