The Trinidad mplementation of FacesBean already supported partialStateSaving, and for Trinidad's JSF 2 offerings it's now a PartialStateHolder

One reason is FacesBean uses propertyKeys, which allow additional information like capabilities.

Beyond that Andy Schwartz had actually taken a look at this previously. Here's what he found.

In theory the ideal solution should be to remove FacesBean in favor of the new standard APIs. However, in practice, there are two issues:

  1. We need to maintain backwards compatibility.
  2. Trinidad's FacesBean solution is more efficient than the standard solution.

Note that the compatibility issues (#1) mainly impact component/renderer authors (not application developers), yet is still an important issue for us.

Regarding efficiency (#2)... FacesBean has two benefits over the standard solution. First, FacesBean supports indexed property keys, allowing for very efficient property lookups. Second, the Trinidad approach avoids overhead involved in the JSF's attribute-property transparency mechanism. When using the JSF implementation of UIComponent.getAttributes().get("foo"), the following steps are performed:

This approach allows property look ups to be more easily customized via subclassing (ie. by overriding accessor methods). Trinidad sacrifices this flexibility for performance. Attribute lookups are routed directly to the FacesBean without invoking component accessor methods.