It would be nice if jsf made all these event signatures optional. I know its a stumbling block for many users. Perhaps the ability to inject those parameters with an annotation (or access via facesContext.getCurrentSystemEvent() ... obviously just a short winded concept. But the idea is to somehow provide optional access.) Lincoln Baxter's Droid http://ocpsoft.com http://scrumshark.com Keep it simple. On Jan 21, 2010 10:19 PM, "Cay Horstmann" <cay(a)horstmann.com&gt; wrote: Consulting the specification for f:event ( http://java.sun.com/javaee/javaserverfaces/2.0/docs/pdldocs/facelets/f/ev...), I find that the signature is required to match public void listener(javax.faces.event.ComponentSystemEvent event) throws javax.faces.event.AbortProcessingException. That's actually too bad. When I do a preRenderView event with viewParams, I don't need the CSE parameter, and I'd rather not couple my managed bean with the JSF API. So, it sure would be nice if I had the flexibility of using the signature public void listener() instead. Mojarra actually lets me do that! I am asking here and not in the Mojarra forum because I am hoping that the f:event spec isn't accurate--it has other issues ( https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=586, https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=639, https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=712 ) Did you discuss this before? Does Mojarra implement what was intended? Thanks, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com

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.

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".

The reason you want to make it so is to have a better unit testing story. Cay

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 >

+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 >