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"