On 19.02.2010 20:25, Kin-man Chung wrote:
> First, let me introduce Christoph Beck. Christoph is the creator of
> JUEL (http://juel.sourceforge.net), a quality implementation of the
> EL 2.1, and more.
>
Thanks (for the quality word)... Before discussing usage enhancements
and new features, I would like to make a proposal to clarify and improve
the current API. From my experience with JUEL and various user
discussions, some of the major sources of trouble are:
- ELContext mixes parse time and evaluation time concerns. Users don't
understand that variables and functions are only used at parse time
while resolvers are only used at evaluation time. The EL should
emphasize this important concept by splitting the ELContext into
ELParseContext and ELEvaluationContext.
- The EL currently does not provide a generalized concept for type
conversions. Many users would like to introduce their own conversion
rules. It's pretty easy to support this by introducing an
ELTypeConverter interface and exposing it in ELEvaluationContext. The
type converter would be used by the AST nodes for operand conversions
but also by ELResolver#invoke(...) to convert method parameters.
I'm not sure in what way we have to deal with backward compatibility. Do
we need binary compatibility (i.e legacy code runs without recompilation)?
Anyway, to summarize, here's some rough code describing the proposed API
changes:
public interface ELParseContext {
public FunctionMapper getFunctionMapper();
public VariableMapper getVariableMapper();
}
public interface ELTypeConverter {
public <T> T coerceToType(Object value, Class<T> type) throws
ELException;
}
public abstract class ELEvaluationContext {
// ... everything from ELContext except the two methods that went
into ELParseContext plus...
public ELTypeConverter getTypeConverter();
}
The methods in ExpressionFactory to create value/method expressions
would now take an ELParseContext parameter. Furthermore, an
ExpressionFactory implements the ELTypeConverter interface:
public abstract class ExpressionFactory implements ELTypeConverter {
// ...
public abstract ValueExpression
createValueExpression(ELParseContext context, ...);
public abstract MethodExpression
createMethodExpression(ELParseContext context, ...);
}
Everywhere else in the API, ELContext would be replaced by
ELEvaluationContext. The ELContext could live on for backward
compatibility:
@Deprecated
public abstract class ELContext extends ELEvaluationContext implements
ELParseContext {
}