Hi Lincoln -
lincolnbaxter(a)gmail.com wrote:
Andy, I lie that idea.
But personally I just like losing the event param altogether for now.
This will enable calling any bean method on an event.
My reason: I don't want to introduce extra restrictions, method signatures, or info
that people need to know in order to use something that should be simple, unless it works
either way.
Just to clarify... I was not proposing that we should place any extra
restriction/method signature on the user. I wonder whether perhaps my
use of the term "implicit object" was confusing... I did not mean to
imply that listeners would be forced to consume this implicit object,
just that we expose the FacesEvent in an EL-reachable locations, thus
making it available for use in method expressions.
So, the page author could do this:
#{bb.valueChangeListener(event, myparam)}
Or this:
#{bb.valueChangeListener(myparam, event)}
But this doesn't have any impact on your preferred solution, ie. the
user could also do this:
#{bb.valueChangeListener(myparam)}
Or:
#{bb.valueChangeListener(someManagedBean.foo, requestScope.bar,
component.clientId, event)}
Once we have support for invoking methods with arbitrary arguments, we
don't especially care what the user's method signature looks like.
I see the action attr as less of a valuechange event, but just a plain method called when
the valuechange occurrs.
Eventually I would like to see it work both ways, but for now I think it will be
intuitive and simple.
In conclusion: Ill submit my impl, and if someone wants to do this in addition, while
still supporting the basic function I'm including, go for it!
Sure. We can definitely tackle this part of the problem separately. :-)
Andy
Lincoln
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Andy Schwartz <andy.schwartz(a)oracle.com>
Date: Fri, 04 Sep 2009 14:46:06
To: <jsr-314-open(a)jcp.org>
Subject: Re: <h:dataTable> binding vs. ui:repeat
Finally read through this thread. Fun stuff. :-)
Martin Marinschek wrote:
> Hi Ed,
>
>
>
>> Which I still don't understand. Can you please explain explicitly?
>>
>>
> I sent a mail to Kin-Man that we can't pass parameters from the
> framework to the method-expression. So, we can now do:
>
> #{bb.action(myparam)}
>
> to call a method with signature:
>
> public String action(String myparam) {}
>
> but we can not do:
>
> #{bb.valueChangeListener(myparam)}
>
> to call a method with signature:
>
> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
>
> only with signature:
>
> public void valueChangeListener(String myparam) {}
>
> so what we loose is the ValueChangeEvent, which was provided by the
> JSF framework as a parameter to the invoke-call in the
> Method-Expression instance (we will only receive the parsed
> parameters).
>
>
An alternative that I believe we could implement in the JSF layer
without any changes to the EL spec would be to provdie access to an
implicit "event" object during event delivery. The page author would
specify:
> #{bb.valueChangeListener(event, myparam)}
>
Where bb.valueChangeListener is bound to:
> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
>
And the "event" implicit object is set up by JSF to point to the
ValueChangeEvent (or more generally, to whatever FacesEvent we happen to
be delivering) just prior to invoking any listeners.
This seems like a perfectly reasonable solution to me, and doesn't
require any special handling of expected/actual parameter types in the
EL layer.
Andy