[ http://jira.jboss.com/jira/browse/JBSEAM-1117?page=comments#action_12357528 ] Bradley Smith commented on JBSEAM-1117: --------------------------------------- oh yes - would it be possible to allow for a single @RaiseEvent annotation to raise multiple events - i.e. an array of event values, types? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1117?page=comments#action_12357539 ] Adam Brod commented on JBSEAM-1117: ----------------------------------- As for supporting Enums, I agree this would be a great addition. However, there is no way for the RaiseEvent/Observer annotations to take user-defined Enums as a parameter. The closest thing I could think of would be to allow a Class as a way to define Event types. However, the class would never be instantiated, it would just allow type-safe event types. This might be confusing to most developers and doesn't seem to elegant. {code} @Target(METHOD) @Retention(RUNTIME) @Documented @interface Observer { /** * @return the event type or types to observe */ String[] value() default {}; /** * @return the event type to observe */ Class<?>[] type() default {}; /** * In case no component instance exists, * should a component instance be created to * handle the event, or should the event be * ignored. * * @return true by default */ boolean create() default true; } {code} Then I could define my event types as different classes, UserLoginEvent.class, UserLogoutEvent.class, etc. These could be empty classes with no methods. {code} // this method raises an event @RaiseEvent(type=UserLoginEvent.class) public void login() { ... // this listens for UserLogin events @Observer(type=UserLoginEvent.class) public void storeUserLoginRecord() { // insert something in the db } {code} If you don't like using classes to define Event types, I guess you could allow enums for people that want to use the Events api directly (not with Annotations). Events would have to overload raiseEvent() like this: {code} public <T extends Enum> void raiseEvent(T type, Object... parameters) {code} Inside Init, we'd have to change/overload getObserverMethodBindings to take an Enum. Then I could raise an event like this: {code} public void login() { Events.instance.raiseEvent(UserEvents.LOGIN); // do some login logic } {code} These both seem like nice additions to the API, but they both have tradeoffs and complicate the current model. It might be best just to stick to Strings and tell users to use Constant files to get type-safety with events. I guesss the Seam team needs to decide what makes for the most powerful api. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1117?page=all ] Gavin King closed JBSEAM-1117. ------------------------------ Fix Version/s: 1.3.0.BETA1 Resolution: Partially Completed Assignee: Gavin King Multiple event types are now supported. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira