Re: [faces-dev] Outstanding enhancement request for Jakarta EL

[Mark Thomas <markt@xxxxxxxxxx>]

On 22/02/2021 13:40, Thomas Andraschko wrote:
> any feedback, Mark? :)

Hi,

Sorry I have taken a while to reply.

I agree with you that there are two solutions as you set out below. More
commentary in-line.

> Am Fr., 5. Feb. 2021 um 12:19 Uhr schrieb Thomas Andraschko
> <tandraschko@xxxxxxxxxx <mailto:tandraschko@xxxxxxxxxx>>:
> 
>     Hi Mark,
> 
>     just to be clear, this is what JSF always does and i dont think that
>     this should be changed, everything should be in EL.
> 
>     MethodExpression me =
>     ExpressionFactory#createMethodExpression(context, expressionString,
>     new Class[] { AjaxBehaviorEvent.class })
>     me.invoke(context, new Object[] {  ajaxBehaviorEventInstance });
> 
> 
>     I think there are 2 solutions for the EL specs / impl:
> 
>     1) add a syntax to reference a "implicit" param, maybe similar to JS:
>         #{bean.method(arguments[0],  someVar)}

This solution does not require any changes to the EL specification. It
does require (relatively simple) changes to the JSF. In summary:

- define "event" as referring to the appropriate AjaxBehaviorEvent

- users would then us #{bean.method(event, someVar)}

- JSF would evaluate this in an ELContext that resolved "event" to the
  appropriate (creating if necessary) AjaxBehaviorEvent instance


I also looked into several variations of this but for a solution where
the user indicates (e.g. via an additional parameter in the method) they
want to receive the AjaxBehaviorEvent the approach above is by far the
simplest to implement - both for EL and JSF.


>     2) add some auto-lookup-magic into EL, like you mentioned in the
>     last mail

This is more complex that option 1. The search order needs to be well
defined. If user specifies #{bean.method(someVar)} then, if both exist,
which is used in preference method(event, someVar) or method(someVar)?
If there is any requirement to make that preference configurable you are
- essentially - back at option 1 and a simpler solution.

Assuming a preference order can be defined, there needs to be sufficient
API exposed to:

- determine if a method with the additional parameter exists
- execute that method with the additional parameter provided by the
  caller

How much of this is bundled up into a single API call to EL vs EL being
extended with a handful of new generic methods to allow a range of
manipulations on MethodExpressions is TBD. The generic approach requires
more work in both EL and JSF but provides for greater flexibility.

>     I >personally< like 1) more as it forces the user to think about the
>     method-mapping and is more flexible.

+1 I think this is the much better solution for this particular problem.

>     2) is of course also nice but we need a lot of fallbacks. Not sure
>     about the performance here, but probably the resolved method is
>     cached in the "MethodExpression" instance?

Maybe. That would be an issue for the EL implementations rather than the
API.


So, in summary, I think the best way forward is option one which should
be implementable in JSF without any changes to the EL API.

Kind regards,

Mark