On 03/23/10 04:38, Martin Marinschek wrote:
> 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?
>
Reasonable, but it still needs token look-ahead during parsing.
If we apply look-ahead to our original "natural" syntax,
#{com.acme.Functions.myFunction()}.
The parser can determine that "com.acme.Functions" is actually the
name of a "package + class", and decide that this is potentially a
static method invocation.
I'll need to look a the Glassfish EL implementation to see if the
grammar can be easily changed to do this. For those who have
implemented EL before, can you also take a look, from easy of
implementation angle? Thanks.
In addition, I think it'll be useful to add in the API, some kind of
import function. For instance,, we can have
elProcessor.import("com.acme.Functions");
then the static methods of this class can be used in the expression
#{Functions.myFunctio()}
BTW, we have exactly the same problem with Enum literals, such as
com.acme.Days.MONDAY, so anything we use here can also be used there!
-Kin-man
> 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.
>
I stand corrected then. In that case, FunctionMapper will not be
deprecated, but will coexist with new way of calling static methods.
-Kin-man
> 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
>>>
>>
>>
>
>