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

[lincolnbaxter at gmail.com]

I understant now, and I agree! I like that a lot.
Sent from my Verizon Wireless BlackBerry

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

Date: Fri, 04 Sep 2009 15:21:20 
To: <lincolnbaxter at gmail.com>; <jsr-314-open at jcp.org>
Subject: Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat


Hi Lincoln -

lincolnbaxter at 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 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
>
>