I take back my previous concept. I think making the parameters optional is good enough. No need for anything fancy.<br><br>+1 for my own first thought, lol<br><br><div class="gmail_quote">On Fri, Jan 22, 2010 at 7:50 PM, Cagatay Civici <span dir="ltr"><<a href="mailto:cagatay.civici@gmail.com">cagatay.civici@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">+1 as well, most of the time it's a burden to add the unused event parameter.<br>
<font color="#888888"><br>
Cagatay<br>
</font><div><div></div><div class="h5"><br>
On Jan 22, 2010, at 8:08 PM, Jason Lee wrote:<br>
<br>
> +1<br>
><br>
> 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<br>
><br>
> On 1/22/10 1:57 PM, Andy Schwartz wrote:<br>
>> Cay Horstmann wrote:<br>
>>> On 01/22/2010 08:52 AM, Kito Mann wrote:<br>
>>>> Personally, I don't think there's anything wrong with having a signature<br>
>>>> that requires an event listener. Isn't that how most UI toolkits work?<br>
>>>> What about Swing or SWT?<br>
>>>><br>
>>>> I do understand the desire to have some code completely decoupled,<br>
>>>> though. If we make the signature optional, though, I'm afraid that'll be<br>
>>>> even more confusing for users.<br>
>>><br>
>>> I don't think it is confusing to say "This parameter is optional". Lots of things are optional in JSF.<br>
>><br>
>> 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:<br>
>><br>
>><br>
>>> 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".<br>
>><br>
>><br>
>> Given that, my take is that:<br>
>><br>
>> 1. Our biggest risk of confusion would be to have the the spec be inconsistent between these cases.<br>
>> 2. The behavior specified for actionListener (event parameter is optional) is the preferred behavior. (We intentionally added this behavior in 2.0).<br>
>> 3. The fact that Mojarra implements this behavior for f:event's listener attribute as well is a good thing (and probably intentional).<br>
>> 4. We should update the spec in our upcoming MR to clarify that the current behavior is by design.<br>
>><br>
>> I have logged the following spec issue to track this:<br>
>><br>
>> <a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=731" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=731</a><br>
>><br>
>> Andy<br>
>><br>
>>> The reason you want to make it so is to have a better unit testing story.<br>
>>><br>
>>> Cay<br>
>>><br>
>><br>
><br>
><br>
> --<br>
> Jason Lee, SCJP<br>
> President, Oklahoma City Java Users Group<br>
> Senior Java Developer, Sun Microsystems<br>
> <a href="http://blogs.steeplesoft.com" target="_blank">http://blogs.steeplesoft.com</a><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>"Keep it Simple"<br>