[jsr-314-open] <h:dataTable> binding vs. ui:repeat

[lincolnbaxter at gmail.com]

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. 

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!

Lincoln
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Andy Schwartz <andy.schwartz at oracle.com>

Date: Fri, 04 Sep 2009 14:46:06 
To: <jsr-314-open at jcp.org>
Subject: Re: [jsr-314-open] <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