On 02/21/10 00:50, Christoph Beck wrote:
> 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.
Good idea to separate the ELContext. If I remember correctly, this was
actually raised in JSP 2.1, but it was late in the spec release cycle,
and was canned for the next release. Well this is the next release!
> - 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.
>
Or we can introduce a convert method in the ELResolver that
handles type conversions.
> 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)?
Yea, we'll need to maintain backward compatibility. We can deprecate
API's but not remove them. :-)
-Kin-man
> 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 {
> }
>