| Re: [faces-dev] Outstanding enhancement request for Jakarta EL |
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
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev