public interface TempVarELResolver
This interface is used to identify ELResolvers that are capable of managing
"temporary" EL variables.
Temporary EL variables (eg. the af:table "var") have historically been stored
directly in the request attribute map. However, this implementation choice
is at odds with the ADF Faces "dirty" postback payload optimization. When
this optimization is enabled, ADF Faces keeps track of which editable components
have been modified by the end user. Only parameters corresponding to modified
("dirty") components are included in the postback payload.
This optimization has the potential to break the case where the edtiable component's
value is stored in request scope. As such, ADF Faces automatically tracks whether
each editable component accesses request scope while retrieving its value. Components
which depend on request scope values are excluded from the dirty postback optimization - ie.
the values for these components are always included in the postback payload, whether
dirty or not.
Thus, editable components that are bound to temporary EL variables that happen to be
stored in request attribute map are not able to participate in the dirty postback
optimization.
When the dirty postback optimization is enabled, ADF Faces wraps the ELResolver chain
with a TempVarELResolver implementation stores temporary EL variables without accessing
the request attribute map. As a result, editable components that are bound to
temporary EL variables are able to participate in the dirty postback optimization.
This solution has two other performance-related benefits over a request attribute-map
based solution.
1. Modifications to the request attribute map result in delivery of
ServletRequestAttributeEvents. The TempVarELResolver approach avoids this
overhead.
2. Values that are stored in the request attribute map are resolved very late in
the ELResolver chain. The TempVarELResolver approach ensures that temporary
EL variables are resolved before any other resolvers are invoked.
Since temporary EL variables are typically accessed many times (eg. every EL expression in
every row for every stamped component in an af:table), #2 can be a significant optimization.