I think allowing static methods is fine, as long as the "end-user" cannot
inject bad things. Otherwise, I agree, "bad-practice" is not a good reason
to disallow a technically viable method of development.
In my opinion of course :)
On Thu, Mar 18, 2010 at 2:12 PM, Kin-man Chung <Kin-Man.Chung_at_sun.com>wrote:
>
>
> 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
>>
>>
> ---------------------------------------------------------------------
> 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
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"