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

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 >