On 03/17/10 19:13, Christoph Beck wrote:
> 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..
>
But we have no way of preventing a user from making such stupid calls,
and that shouldn't be the reason to disallow static functions.
Static functions, and with it FunctionMapper, was in EL before the more
general method call was introduced in EL. To me, the need to register
a function before it can be used places an unnecessary burden on the
user. In JSP, functions are registered in the TLDs. Now that JSF2.0
is not using JSP anymore, functions are not used much because it is
hard to use.
I would like the hear other opinions from this group, as this IS
important.
However, we should talk about easing the way functions are registered
programmatically. Any suggestion?
One difficulty is getting a java.lang.reflect.Method required by
FunctionMapper. I think we should let the EL engine does this. The
best I can think of is something like:
elProcessor.registerFunction("x", "org.acme.bar.func");
elProcessor.getValue("#{x()}";
Alternatively, we can import the package name into EL, and use it in the
call.
elProcessor.import("p", "org.acme.bar");
elProcessor.getValue("#{p.func()}";
Hmmm, I like this better, because it hides the idea of function
registration from the user. I'm sure the imported package can be used
elsewhere in EL. Also in terms of implementation, "p" can be an EL
variable and that seems to fix into current EL.
- Kin-man
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
>