[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
