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.