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

[Jason Lee]

+1

I'd wager that half the time I don't need the parameter I'm required to 
pass in, so I'd love to this made optional.  Officially.

On 1/22/10 1:57 PM, Andy Schwartz wrote:
> 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
>>
>


-- 
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com