Kin-man Chung wrote:
>
>
> On 03/17/10 15:59, Jason Porter wrote:
>> On Wed, Mar 17, 2010 at 16:39, Kin-man Chung<Kin-Man.Chung_at_sun.com>
>> wrote:
>>>
>>> Since we already allow methods in EL expressions in EL 2.2, we should
>>> extend this to include static methods. The most obvious syntax to use
>>> is to include the package name, such as
>>>
>>> "#{com.acme.bar.method())"
>>>
>>> The downside is that we are overloading the meaning of the . operator
>>> here, and might cause problems in parsing. There may be other ways.
>>
I think this is neither needed nor desirable. We can't allow any static
methods anyway (${java.lang.System.exit(-1)}). I would prefer to ease
the way functions are registered programatically..
>> Would be it too much to assume that the class would already be a bean
>> that we could resolve? If we had that limitation then we avoid the
>> package problem. Although not having to have the class be resolvable
>> via any other lookup would really increase the pool of allowable
>> functions such as things from Apache commons-lang.
>
> Well, the point of using a static method is not requiring an bean
> instance. We should not have such restriction.
>
>>
>> We could control those classes with a file in the META-INF say
>> META-INF/staticFunctions or some other name that would a newline
>> delimited FQN of the class that contains static methods, then look
>> through those for a matching method signature. Probably not a great
>> idea, but it may stir other thoughts.
>>
> I don't like having another file for this. Its also won't work well
> outside of web container. It'd be best if we can have the necessary
> pieces in EL itself, if not in the expression, at least in the API.
dito
>
>>> I'd assume we'd deprecate FunctionMapper and not include it in
>>> ELProcessor.
I see no reason for this. It doesn't hurt and it's not in the way for
something else. The ELProcessor does not have to expose it. In general I
think we should leave the classic EL API intact where possible.
>>>
>>> -Kin-man
>>
>
> ---------------------------------------------------------------------
> 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
>