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"