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

[Lincoln Baxter, III]

I take back my previous concept. I think making the parameters optional is
good enough. No need for anything fancy.

+1 for my own first thought, lol

On Fri, Jan 22, 2010 at 7:50 PM, Cagatay Civici <cagatay.civici at gmail.com>wrote:

> +1 as well, most of the time it's a burden to add the unused event
> parameter.
>
> Cagatay
>
> On Jan 22, 2010, at 8:08 PM, Jason Lee wrote:
>
> > +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
> >
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100122/2af1c219/attachment.html