On 08/03/11 06:59, Ramesh wrote:
> My only concern is in the case of JSP container. Giving a way to
> alter the function mapper might give a way to override the container
> instantiated FunctionMapper.
True. But this is already currently possible if a JSP programmer try
really hard: he can always construct a new ELContext with a new
FunctionMapper.
The current EL was designed with web container in mind, and some of the
design principles need to be updated or modified when applied to the
stand-alone EL. In this case, we either add a setter in the
FunctionMapper, or we define a new StandAloneFunctionMapper that
contains a setter, and use that exclusively in ELProcessor. The latter
approach would create two independent APIs, which we said we should avoid.
I think adding a setter is a small price to pay for a unified EL.
> In case we need a setter, there should be a way to validate saying the
> Web application cannot alter the FunctionMapper.
>
This is an issue for the JSP spec, not EL spec. If needed, a JSP
container can prevent a JSP user from using the setter, by always
throwing an exception when is called.
Kin-man
> Ramesh
>
> On 8/3/2011 1:18 AM, Kin-man Chung wrote:
>> While implementing ELProcessor and ELManager, I discovered some
>> idiosyncrasies with ELContext and FunctionMapper. In FunctionMapper,
>> while there is a getter for the function map, there is no setter. The
>> same in ELContext for ELResolver. I understand the orginal desinger's
>> desire to not allow changes to these instances after the initial
>> construction, presumably to allow optimizations in expression
>> evaluations.
>>
>> Personally, I have not seen any implementation of the EL that can take
>> advantage of this to do useful optimizations. Also, that philosophy
>> seems to go against our current design for stand-alone EL, which allows
>> ELResolvers and functions to be added anytime. The expectation for
>> stand-alone EL is that it will be used in a more dynamic environments.
>>
>> Therefore, I am proposing adding a setter for functions in the
>> FunctionMapper. Curiously, there is already a setter for variables in
>> VariableMapper. I think I can work around the lack of a setter for
>> ELResovers in ELContext, and leave it alone for now.
>>
>> If there are objections to this, please let me know.
>>
>> Kin-man
>>