Hi guys,
I would love to have the ability to call static functions directly -
so my +1. However, I do see the parsing problems you point out,
Kin-Man.
How about the following: we would device a new namespace, a
classpath-namespace for the Unified EL:
new namespace:
http://unified.el/classpath, prefix e.g. cp
and then could do the following:
#{cp:com.acme.functions.MyFunction()}
Does that sound reasonable?
Alternatively, I would say that this is an issue where annotations
would definitely help to reduce the configuration clutter!
And by the way, as to your remarks JSF 2: facelets also has a
possibility to register EL-functions, and we use that extensively in
our projects, so contrary to what you say, I think this is widely used
in the JSF space.
best regards,
Martin
On 3/22/10, Mike Brock <cbrock_at_redhat.com> wrote:
> +1
>
> This was originally one of those major limitations that really precipitated
> my decision to start developing MVEL. MVEL, of course, adopts plain
> Java-syntax for static calls, which I think makes the most amount of sense
> and is obviously very useful.
>
> That said, I think it makes sense to be able to alias static methods as
> functions. The approach we've taken, which is probably a little too
> heavy-weight for the EL spec, is through the introduction of full
> function-pointer support at the language and runtime level. So, you're
> fundamentally able to do something like this:
>
> time = System.currentTimeMillis; // reference the method
> time(); // call it.
>
> However, this has the useful side-effect of allowing you to inject functions
> as regular variables from the API:
>
> Map<String, Object> vars = new HashMap<String, Object>();
> vars.put("time", System.class.getMethod("currentTimeMillis"));
>
> long time = MVEL.eval("time()", vars, Long.class);
>
> Just food for thought.
>
> Mike.
>
> On 2010-03-17, at 6:39 PM, Kin-man Chung wrote:
>
>> Current EL allows static functions to be invoked by the use of a
>> FunctionMapper. See java.el package in
>> http://java.sun.com/javaee/5/docs/api/
>>
>> For instance, if the prefix "pre" and "foo" maps to the method
>> com.acme.bar.method, then the expression
>>
>> "#{pre:foo()}"
>>
>> cuases this method to be invoked.
>>
>> The need for both the prefix and a name, which can be unrelated
>> to the actual method name, is clunky and unintuitive, and has its
>> roots in JSP.
>>
>> 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'd assume we'd deprecate FunctionMapper and not include it in
>> ELProcessor.
>>
>> -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
>>
>
> On 2010-03-17, at 6:39 PM, Kin-man Chung wrote:
>
>> Current EL allows static functions to be invoked by the use of a
>> FunctionMapper. See java.el package in
>> http://java.sun.com/javaee/5/docs/api/
>>
>> For instance, if the prefix "pre" and "foo" maps to the method
>> com.acme.bar.method, then the expression
>>
>> "#{pre:foo()}"
>>
>> cuases this method to be invoked.
>>
>> The need for both the prefix and a name, which can be unrelated
>> to the actual method name, is clunky and unintuitive, and has its
>> roots in JSP.
>>
>> 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'd assume we'd deprecate FunctionMapper and not include it in
>> ELProcessor.
>>
>> -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
>>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces