[jsr-314-open] Fwd: [Issue 6] New - Framework (caller) provided parameters get lost with the new method-expression param functionality

[Martin Marinschek]

For your information - my discussion with Kin Man on our desired
extension to the Unified EL.

(we need a way to pass in the JSF supplied parameters to methods with
user-specified params as well).

Kin-Man's suggestion is that in a next revision we will be able to use:

#{myNs:myMethod(*, myParam)}

which sounds great to me!

best regards,

Martin


---------- Forwarded message ----------
From: Martin Marinschek <mmarinschek at apache.org>
Date: Thu, Jan 21, 2010 at 7:42 AM
Subject: Re: [jsr-314-open] [Issue 6] New - Framework (caller) provided parameters
get lost with the new method-expression param functionality
To: Kin-Man.Chung at sun.com


>> we came to the conclusion that there should be two
>> possibilities: either the method which is being called only takes the
>> parsed parameters, then it should be called with these params only, or
>
> This how EL behaves now.  :-)

agreed

>> it takes more than these, than the additional params should be taken
>> over from the invoke-method call and passed on to the method. I see it
>> rather counter-intuitive and confusing that params that
>> method-listeners in JSF have always received (like the ActionEvent or
>> the ValueChangeEvent, certainly an important parameter) are suddenly
>> not available anymore.
>
> Just a clarification about what I think is confusing.
>
> If you create an MethodExpression with
>
>   ExpressionFactory.createMethodExpression(
>       elContext,
>       "#{myBean.method("param")",
>       String.class,
>       Object[] {String.class} )


JSF doesn't create a method expression like this, it creates a method
expression like this:

  ExpressionFactory.createMethodExpression(
      elContext,
      userSuppliedString,
      String.class,
      Object[] {String.class} )

so for JSF it is not counter intuitive or confusing that the method
suddenly gets an additional parameter from the user - it doesn't even
know about it. JSF (the framework) needs to pass some params to the
method, and it is counter-intuitive and confusing if these params
don't end up in the method!

> you are telling EL to create an expression that represents a method with
> one parameter of String type, but now you want to invoke a method with
> two parameters.  This is counter-intuitive and confusing.

You disagree with yourself here: the types that you pass in to the
create method expression call from above don't mean anything at all
(or else the new method invocation will not work at all, cause your
custom method expression signatures would all need to take
ActionListeners, and that would really be dumb)!

To make my point clearer - you could do this:

>   ExpressionFactory.createMethodExpression(
>       elContext,
>       "#{myBean.method("param")",
>       String.class,
>       Object[] {FacesContext.class,Object.class, Object.class} )

And it would still call a method with the signature Bean.method(String
param) even though you supplied three parameters! (I didn't actually
test this assumption, but it has to work, or these user supplied
method parameters don't make sense at all for JSF, cause JSF will
always supply its own set of parameters).

The types and then the params which are passed in are ignored,
everything that counts is what is passed in from the user! The
confusing thing is that the current situation is ignoring stuff here,
not that whatever is parsed is off from what is passed in (that is
already true with the current situation).

> If you want the previous behavior, then you should use the old EL syntax
> #{myBean.method}.

With which you are saying: ok, you JSF folks cannot use user supplied
parameters properly. Thanks!

> Anyway, you also didn't say how EL can decide which of the two
> possibilities to take.

There should be a possibility to check which method signatures are
there - there is even an API now (I think it was in the EL resolver,
right?) where we can go look to find the proper method signature
ourselves, but we can't, cause we don't get the second set of
parameters there.

>>> When JSF framework passes the parameters to MethodExpression.invoke(),
>>> are the parameter types compatible with those expected by this
>>> instance of MethodExpression?  How are this MethodExpression and
>>> parameters instantiated?

yes, but they will not be what is passed in from the user - that is
what I keep saying.

>> As before - there is some factory method for creating a
>> method-expression called - you should know this better than me, so I
>> am not gonna look it up right now - and the expected params are passed
>> in at creation time. As I see it, in the new version both the expected
>> param types and the actual param instances are ignored and instead the
>> parsed instances are taken over.
>>
> I though this is what JSF wanted, as conveyed to me by Ed Burns and
> Jacob Hookom.  This also how the Jboss EL behaves too.

I don't know what exactly they conveyed to you, Jacob e.g. is not very
active anymore on the EG (he hasn't been for years). Ed will have
given you a big picture, but that was a detail that we discussed early
on, then we had heard that yes, it was supported (obviously we didn't
get the response from you directly) and then later we found out it
wouldn't work (and this was when I contacted you).

>>> Guess what I trying to figure out is: how can the EL API be modified to
>>> do what you want to achieve.  So far I don't have a very clear picture.
>>
>> Well, it would have been great if we could have had that discussion a
>> little earlier (before the API was released) - I am not sure how this
>> would fit into the newly released API, either. My original suggestion
>> back in (I think) May was, if you couldn't do it by default, that you
>
> Nobody has talked to me about this before you did, but the EL MR was
> already closed then.

we really had an information problem - the EGs all should be _way_
more open, then this would work a lot better.

>> would provide us with a way where we could somehow get both sets of
>> parameters in the ELResolver and choose ourselves what method to call
>> - then we could easily fix this in a custom EL Resolver. Anyways - if
>> you want to help out the JSF EG, then it would certainly be great you
>> would take a look into this.
>>
> I don't think ELResolver is the answer.  It is too much a hack.
>
> Maybe we can modify the EL syntax to allow for something like
>
>    #{myBean.method(*, param)"
>
> and the "*" would instruct EL to take the parameters supplied when the
> MethodExpression was created, and prepend them to the list of parameters
> used for method selection and invocation.  Would this work for you?

Sounds very good to me!

> Ah, we need a JSR for EL to discuss things like this!

Yes, definitely. Dan Allen even wrote  a blog entry about the need for
a Unified EL EG.

> Should we get
> other JSF EGs involve so to get a consensus?

I will forward this mail to the JSF EG. Thanks for your feedback.

> -Kin-man

best regards,

Martin

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces