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