Framework (caller) provided parameters get lost with the new method-expression param functionality

[glassfishrobot]

Find enclosed a mail from the JSF EG. I was asked to create a new issue from this in the UEL issue tracker. The issue is that framework(caller)-parameters get lost as soon as you provide parameters from the EL-expression itself.

I am sorry for the term framework(caller)-parameters - I did not find a better way to name these parameters. Formal parameters are something else, parsed parameters are also something else - if you have a better term, please set me straight.

Proposed behaviour: if a method with this signature is present, the framework (caller)-supplied parameters should be prepended to the parsed parameters.

regards,

Martin

MM> I sent a mail to Kin-Man that we can't pass parameters from the MM> framework to the method-expression. So, we can now do:

MM> #

{bb.action(myparam)}

MM> to call a method with signature:

MM> public String action(String myparam) {}

MM> but we can not do:

MM> #

{bb.valueChangeListener(myparam)}

MM> to call a method with signature:

MM> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}

MM> only with signature:

MM> public void valueChangeListener(String myparam) {}

MM> so what we loose is the ValueChangeEvent, which was provided by the MM> JSF framework as a parameter to the invoke-call in the MM> Method-Expression instance (we will only receive the parsed MM> parameters).

Thanks. Now I understand your request.

MM> I already got mail by Kin-Man - he said this won't be included, we MM> are too late.

MM> This effectively means we cannot use the new EL functionality to solve MM> the problem that was discussed in this thread (using MM> valueChangeListeners in a dataTable), and therefore, even though we MM> can get rid of the f:setPropertyActionListener, we would still need an MM> f:setPropertyValueChangeListener - a pity.

Environment

Operating System: All Platform: Macintosh

Affected Versions

[current]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/uel-ri/issues/6
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[glassfishrobot]

@glassfishrobot Commented Reported by mmarinschek

[glassfishrobot]

@glassfishrobot Commented Was assigned to uel-issues

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA UEL-6

[markt-asf]

There has been along discussion about this request on the Jakarta faces dev list: https://www.eclipse.org/lists/faces-dev/msg00103.html

The very abbreviated summary of that discussion is that the functionality being requested could be best met by either adding an additional implict variable to the implicit variables already supported by Jakarta Faces or by an additional custom ELResolver in Jakarta Faces.

Given the above, I am closing this issue as WONTFIX.