Should JSF go stateless?

Jacob Hookom's written an interesting blog entry about whether JSF could go stateless. The two of us have gone back and forth on this on e-mail a bunch of times, and I guess you could say that I fall in the "UI state is a good thing" camp. In large part, that comes from all the time I've spent working on component frameworks.

I absolutely agree with Jacob on one of his points - "Statesaving in JSF is [really] bad in implementation". It's a massive and heavyweight "save everything on the page" approach that is, at least conceptually, horrible overkill. For example, it's ridiculous that we have to save the UI component hierarchy, attributes, EL expressions, etc., when we have a JSP or Facelets document containing exactly that information just sitting there on the server. Even though I know why this happened - JSF had to support JSPs, etc., etc. - it's a very frustrating state of affairs.

Nevertheless, I think throwing out state saving altogether in response would be going too far. It'd be like saying that you should never bother sorting because Bubble Sort is a really slow algorithm. Unfortunately, JSF, as designed today, makes it very difficult to even attempt to optimize state saving. Until there's a really sane, solid implementation of state saving, any big policy decisions are premature.

The real problem with optimizing JSF state saving is the way that UIComponent.saveState() (and restoreState()) is typically implemented. Each class is responsible for saving all of its own per-instance state, up and down the hierarchy. So UIComponentBase stores its properties in an array, then UIOutput stores a few more properties (plus the UIComponentBase state) in an array of its own, then UIInput aggregates its own state, and finally HtmlInputText adds its own. For example, here's the start of HtmlInputText.saveState():

  public Object saveState(FacesContext _context) {
    Object _values[] = new Object[31];
    _values[0] = super.saveState(_context);
    _values[1] = accesskey;
    _values[2] = alt;
    _values[3] = dir;
    _values[4] = this.disabled ? Boolean.TRUE : Boolean.FALSE;
    _values[5] = this.disabled_set ? Boolean.TRUE : Boolean.FALSE;
    .... and on and on and on for another 26 lines ....
  }

Nasty! If a container wanted to optimize state saving, it'd somehow have to mix that in not just into one class, but into every component class up and down the hierarchy.

ADF Faces took a different approach. We store all of our component state in an FacesBean instance. It takes care of storing simple properties, ValueBindings, lists (like listeners and validators), and knows how to save and restore state. Here's the full code for UIXComponentBase.saveState();

  public Object saveState(FacesContext context)
  {
    return getFacesBean().saveState(context);
  }

And subclasses don't neeed any code at all. Aaahhhh..... Now that's better. More on FacesBean in a later post (there's a lot of other advantages), but what's relevant is the general principle: all state saving is implemented up in the base class, so now there's a hook to implement real cross-cutting optimizations like:

• Cache reusable FacesBean instances on a Facelet tag handler (with copy-on-write), especially for panels and output components that rarely if ever mutate


• Implement saveState() that only saves deltas from the original state of the bean (and rely on Facelets to recreate the tree in its original state)

Secondarily, we'd do very well to follow Jacob's advice and re-think how processSaveState() and processRestoreState() function - instead of creating a deep heirarchy, create a flattened Map or array structure.

Implement all of this, and then we're in a place to judge whether fully stateless UIs are necessary. I think they will be, for some limited types of applications, but JSF can be pushed a lot further than it's going now.