[jsr-314-open] Method signatures for event handlers

[Andy Schwartz]

Cay Horstmann wrote:
> On 01/22/2010 08:52 AM, Kito Mann wrote:
>> Personally, I don't think there's anything wrong with having a signature
>> that requires an event listener. Isn't that how most UI toolkits work?
>> What about Swing or SWT?
>>
>> I do understand the desire to have some code completely decoupled,
>> though. If we make the signature optional, though, I'm afraid that'll be
>> even more confusing for users.
>
> I don't think it is confusing to say "This parameter is optional". 
> Lots of things are optional in JSF.

Yep.  Actually, for the nearest equivalent to this use case - 
h:commandButton's actionListener - we have specified that the 
ActionEvent is now optional (as of 2.0 I believe).  From the tag doc:


> The expression must evaluate to a public method that takes an 
> ActionEvent parameter, with a return type of void, or to a public 
> method that takes no arguments with a return type of void. In the 
> latter case, the method has no way of easily knowing where the event 
> came from, but this can be useful in cases where a notification is 
> needed that "some action happened".


Given that, my take is that:

1. Our biggest risk of confusion would be to have the the spec be 
inconsistent between these cases.
2. The behavior specified for actionListener (event parameter is 
optional) is the preferred behavior.  (We intentionally added this 
behavior in 2.0).
3. The fact that Mojarra implements this behavior for f:event's listener 
attribute as well is a good thing (and probably intentional).
4. We should update the spec in our upcoming MR to clarify that the 
current behavior is by design.

I have logged the following spec issue to track this:

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=731

Andy

> The reason you want to make it so is to have a better unit testing story.
>
> Cay
>