Agree with you.
On 8/4/2011 3:23 AM, Kin-man Chung wrote:
> 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
>>>
>
>