[cdi-dev] [JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)

[Christopher Brock (JIRA)]

    [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600511#comment-12600511 ] 

Christopher Brock edited comment on CDI-4 at 5/7/11 2:14 PM:
-------------------------------------------------------------

I do, of course. And I've stewed about this problem for quite a long time. Ever since we needed the ability to control event ordering in Forge and now in some cases, in Errai. 

The problem is that when you're trying to _keep it simple_ you can't discount the possibility that you're merely exporting the complexity of a problem, as well. And I think that while this does add complexity to CDI, it does so in a way that balances the complexity with programmatic intuitiveness, maintains a modicum of readability, leverages qualifiers, and provides frameworks like say, Forge or Errai, with the ability to offer expressive -- and more importantly, documentable -- ways of controlling event-firing across decoupled components.

The truth is, and I know Dan Allen can attest to this, that my initial suggestion was to use magic numbers for salience, as well. And while it's an undeniably simple thing to implement, it will more than likely just produce convoluted code.

I mean, to further my example from earlier -- and not to put to fine a point on it -- but I would cringe to write something like this in my documentation: 

{code}
  In order to ensure that your changes are picked up by the persistence plugin, you must ensure that the CodeChange event observer has a salience of less than 0.7f.
{code}

      was (Author: cbrock):
    I do, of course. And I've stewed about this problem for quite a long time. Ever since we needed the ability to control event ordering in Forge and now in some cases, in Errai. 

The problem is that when you're trying to _keep it simple_ you can't discount the possibility that you're merely exporting the complexity of a problem, as well. And I think that while this does add complexity to CDI, it does so in a way that balances the complexity with programmatic intuitiveness, maintains a modicum of readability, leverages qualifiers, and provides frameworks like say, Forge or Errai, with the ability to offer expressive -- and more importantly, documentable -- ways of controlling event-firing across decoupled components.

The truth is, and I know Dan Allen can attest to this, that my initial suggestion was to use magic numbers for salience, as well. And while it's an undeniably simple thing to implement, it will more than likely just produce convoluted code.

I mean, to further my example from earlier, and not to put to fine a point on it, but I would cringe to write something like this in my documentation: 

{code}
  In order to ensure that your changes are picked up by the persistence plugin, you must ensure that the CodeChange event observer has a salience of less than 0.7f.
{code}
  
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
>                 Key: CDI-4
>                 URL: https://issues.jboss.org/browse/CDI-4
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events, Portable Extensions
>    Affects Versions: 1.0
>         Environment: All
>            Reporter: Lincoln Baxter III
>            Assignee: Christopher Brock
>             Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers. 
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira