+1
On Thu, Mar 18, 2010 at 10:48 PM, Lincoln Baxter, III
<lincolnbaxter_at_gmail.com> wrote:
> Calling static methods would be much more convenient with syntax like:
> #{com.acme.bar.method()}".
> Having to individually register each one seems a burden.
>
> +1 from me
>
>
> On Thu, Mar 18, 2010 at 4:51 PM, Kin-man Chung <Kin-Man.Chung_at_sun.com>
> wrote:
>>
>> Actually, the opinion I am seeking is whether we should continue
>> to use FunctionMapper for mapping a static method to a name, before
>> the method can be called, or whether we should have a new syntax
>> for static methods, such as #{com.acme.bar.method()}".
>>
>>
>> On 03/18/10 11:55, Lincoln Baxter, III wrote:
>>>
>>> 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
>>> <mailto: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
>>> <mailto: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
>>> <mailto:el-next-unsubscribe_at_uel.dev.java.net>
>>> For additional commands, e-mail:
>>> el-next-help_at_uel.dev.java.net
>>> <mailto:el-next-help_at_uel.dev.java.net>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
>>> <mailto:el-next-unsubscribe_at_uel.dev.java.net>
>>> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>>> <mailto:el-next-help_at_uel.dev.java.net>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
>>> <mailto:el-next-unsubscribe_at_uel.dev.java.net>
>>> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>>> <mailto:el-next-help_at_uel.dev.java.net>
>>>
>>>
>>>
>>>
>>> --
>>> Lincoln Baxter, III
>>> http://ocpsoft.com
>>> http://scrumshark.com
>>> "Keep it Simple"
>>
>> ---------------------------------------------------------------------
>> 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"
>