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.
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.
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'd assume we'd deprecate FunctionMapper and not include it in
> ELProcessor.
>
> -Kin-man
--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.
PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu