| Re: [faces-dev] Outstanding enhancement request for Jakarta EL |
On 25/02/2021 17:22, Thomas Andraschko wrote:
> Hi Mark,
>
> in general there are 2 ways where the parameters of the method comes from:
> 1) params passed to MethodExpression#invoke (#{myBean.myMethod}, in our
> case AjaxBehaviorEvent)
> 2) params defined as EL-ref by the user _expression_, which will be
> resolved by ELResolvers (#{myBean.myMethod(someOtherELVar)}
>
> With the approach suggested by my last mail, you can do
> #{myBean.myMethod(arguments[0], someOtherELVar)}.
> IMO its much cleaner as magically try to resolve the method with params
> passed to MethodExpression#invoke and provided in the EL-String.
How is this different to using #{myBean.myMethod(event, someOtherELVar)}
where event is resolved by a JSF provided resolver?
Anything where JSF is able to do something like:
- if this _expression_ contains a method call
- identify the method
- obtain the parameter types and values
- look for a different method on the same object with a different
signature
- switch the _expression_ to use the new method and a newly provided set
of parameters (which may include some, all or non of the original
ones)
- call the new method
is going to require massive change to the EL API. The biggest issue is
that the EL API does not expose the structure of the _expression_. The
magnitude of change required to do this is not justified given simpler
solutions are available with the current API.
Given this, I intend to close issue#6 with a recommendation that an
implicit variable is used along the lines of:
#{myBean.myMethod(event, someOtherELVar)}
Kind regards,
Mark
>
> Best regards,
> Thomas
>
> Am Do., 25. Feb. 2021 um 17:46 Uhr schrieb Mark Thomas <markt@xxxxxxxxxx
> <mailto:markt@xxxxxxxxxx>>:
>
> Thomas,
>
> That would likely be part of an implementation but I really need to
> understand how you would see this working as a user of the EL API. What
> would the EL _expression_ look like? What API would you call to manipulate
> the parameters? I'm struggling to come up with anything that isn't
> significantly messier than using implicit parameters that are then
> resolved by the ELContext.
>
> Mark
>
>
> On 24/02/2021 10:45, Thomas Andraschko wrote:
> > Hi Mark,
> >
> > i think about something like this:
> >
> https://github.com/apache/tomcat/blob/master/java/org/apache/el/MethodExpressionImpl.java#L267
> <https://github.com/apache/tomcat/blob/master/java/org/apache/el/MethodExpressionImpl.java#L267>
> >
> > try {
> > putTempVar("arguments", params);
> > Object result = this.getNode().invoke(ctx, this.paramTypes,
> params);
> > }
> > finally {
> > removeTempVar("arguments");
> > }
> >
> > Do you know what i mean?
> > Maybe you have a good idea to implement this easily :) I did a
> short try
> > it but quite hard to open Tomcat with its Ant build and i dont
> know the
> > EL internals that good like you.
> >
> > Best regards,
> > Thomas
> >
> >
> > Am Mi., 24. Feb. 2021 um 10:22 Uhr schrieb Mark Thomas
> <markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>
> > <mailto:markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>>>:
> >
> > Hi Thomas,
> >
> > Can you provide an example of how you would like this to work
> and the
> > specific changes you are asking for in the EL API as there
> are lots of
> > ways this could be done.
> >
> > Thanks,
> >
> > Mark
> >
> >
> > On 24/02/2021 08:53, Thomas Andraschko wrote:
> > > Hi Mark,
> > >
> > > you may be right that this could be done in JSF only by
> manual push
> > > "event" and the obj instance to the ELContext.
> > >
> > > But i still think this could be a good change for the EL
> specs to
> > > introduce the "arguments" array as there is no way to
> reference the
> > > parameters passed to MethodExpression#invoke.
> > > I like it more to enhance the EL specs instead of changing a
> > > "implementation detail" in JSF (same as e.g. RequestScoped
> should be
> > > implemented in Servlet, not CDI).
> > > It just makes EL a bit more flexible.
> > > I think there might be other usescases as well and the
> > implementation is
> > > quite easy at EL side.
> > >
> > > Best regards,
> > > Thomas
> > >
> > >
> > > Am Di., 23. Feb. 2021 um 15:49 Uhr schrieb Mark Thomas
> > <markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>
> <mailto:markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>>
> > > <mailto:markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>
> <mailto:markt@xxxxxxxxxx <mailto: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> <mailto:tandraschko@xxxxxxxxxx
> <mailto:tandraschko@xxxxxxxxxx>>
> > <mailto:tandraschko@xxxxxxxxxx
> <mailto:tandraschko@xxxxxxxxxx> <mailto:tandraschko@xxxxxxxxxx
> <mailto:tandraschko@xxxxxxxxxx>>>
> > > <mailto:tandraschko@xxxxxxxxxx
> <mailto:tandraschko@xxxxxxxxxx> <mailto:tandraschko@xxxxxxxxxx
> <mailto:tandraschko@xxxxxxxxxx>>
> > <mailto:tandraschko@xxxxxxxxxx
> <mailto:tandraschko@xxxxxxxxxx> <mailto: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 <mailto:faces-dev@xxxxxxxxxxx>
> <mailto:faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>>
> > <mailto:faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>
> <mailto:faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>>>
> > > To unsubscribe from this list, visit
> > > https://www.eclipse.org/mailman/listinfo/faces-dev
> <https://www.eclipse.org/mailman/listinfo/faces-dev>
> > >
> > >
> > > _______________________________________________
> > > faces-dev mailing list
> > > faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>
> <mailto:faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>>
> > > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/faces-dev
> <https://www.eclipse.org/mailman/listinfo/faces-dev>
> > >
> >
> > _______________________________________________
> > faces-dev mailing list
> > faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>
> <mailto:faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>>
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/faces-dev
> <https://www.eclipse.org/mailman/listinfo/faces-dev>
> >
> >
> > _______________________________________________
> > faces-dev mailing list
> > faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/faces-dev
> <https://www.eclipse.org/mailman/listinfo/faces-dev>
> >
>
> _______________________________________________
> faces-dev mailing list
> faces-dev@xxxxxxxxxxx <mailto:faces-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/faces-dev
> <https://www.eclipse.org/mailman/listinfo/faces-dev>
>
>
> _______________________________________________
> faces-dev mailing list
> faces-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
>
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev