[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1117) support enum types in @RaiseEvent or a new @RaiseEventType annotation

[Adam Brod (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.

> support enum types in @RaiseEvent or a new @RaiseEventType annotation
> ---------------------------------------------------------------------
>
>                 Key: JBSEAM-1117
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-1117
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Bradley Smith
>
> RaiseEvent:
> @Target(METHOD)
> @Retention(RUNTIME)
> @Documented
> public @interface RaiseEvent 
> {
>    
>    /**
>     * The event name, defaults to the name
>     * of the method.
>     * 
>     * @return the event name
>     */
>    String value() default "";
>    
>    //TODO: String[] ifOutcome() default {};
>    
> }
> Is it possible to make the value be based on an enum type?  I currently have all my application event types enumerated in enum called EventType.
> I've tried doing:  
> @RaiseEvent(EventType.ApplicationSaved.name())
> however, this doesn't count as a constant String and is invalid syntax.  It seems more 'elegant' to be able to enumerate the event types of an application in something like an enum than to sprinkle strings throughout the code with the specific event String values.
> Maybe an alternate annotation is called for - say, @RaiseEventType(MyEnum.MyEventType)?
> I'm not sure - I don't have a solid grasp of the syntax used to define an annotation.

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