On Feb 22, 2010, at 7:10, Christoph Beck <beck_at_odysseus.de> wrote:
>>
>>> }
>>> 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, ...); }
>>>
>>
>> It seems odd having ExpressionFactory implement ELTypeConverter. I
>> think we would be much better off making this have it's own stage
>> in the EL evaluation pipeline...
>>
>>
>>
>
> You're right. I did this because ExpressionFactory already has the
> coerceToType(...) method. An alternative would be to just remove (or
> @Deprecate) this method.
Probably best to deprecate. Unless we provide a backwards
compatibility layer. On that note, how compatible do we need to be? Is
anything on the table to be changed if needed?
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
>> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>