Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Later
    • Affects Version/s: 1.5-M3
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None

      Description

      It would be nice if Wicket had an application-scoped "event bus" that users could plug into to receive event notifications. Right now, there are multiple points where you can subscribe to events (and no "global" place to subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if you could just do:

      Application.get().getEventBus().subscribe(IRequestCycleListener.class, myListener);

      or perhaps:

      Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener);

      To fire events, you would do something like:

      Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle);

      or

      Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle);

      Or course, this approach uses proxies (the publish methods return proxies which let you fire the events to all listeners) and I know they are considered somewhat taboo, but I think this is a good use of them and I really don't see how debugging this could be that difficult really. It would only need to use JDK proxies, because we'd be dealing with listener interfaces only. The benefit of this is that there's just one way to publish/subscribe events in Wicket and it makes it easier for folks to "plug in." They don't have to override a factory method somewhere to make sure they add their listener or anything. They just ask for the bus and subscribe by listener interface.

      Now, I like the idea of subscribing to a "channel" by means of the listener interface, but I'm open to suggestions if other folks don't really like that idea. I like the type-safety of it.

      I have some code, but I'm waiting for more discussion here before I submit a patch. I'd have to get rid of all of the listener lists that are lying around and start having the events published through the bus.

        Activity

        Hide
        Martin Grigorov added a comment -

        Closing the ticket.
        It seems the current Event system works well for now. There are no complaints in Jira and mailing lists

        Show
        Martin Grigorov added a comment - Closing the ticket. It seems the current Event system works well for now. There are no complaints in Jira and mailing lists
        Hide
        James Carman added a comment -

        Agreed

        Show
        James Carman added a comment - Agreed
        Hide
        Sebastian added a comment -

        Event handling, may it be application wide or between specific component instances is basically "just" about routing messages from senders to receivers. I believe a good designed generic event handling solution should work for both use cases.

        Show
        Sebastian added a comment - Event handling, may it be application wide or between specific component instances is basically "just" about routing messages from senders to receivers. I believe a good designed generic event handling solution should work for both use cases.
        Hide
        James Carman added a comment -

        Well, it looks like they're trying to address two different problems. WICKET-1312 seems to be trying to address loosely-coupled, inter-component communication. This aims to be more of a lifecycle event communication mechanism for the overall framework.

        Show
        James Carman added a comment - Well, it looks like they're trying to address two different problems. WICKET-1312 seems to be trying to address loosely-coupled, inter-component communication. This aims to be more of a lifecycle event communication mechanism for the overall framework.
        Hide
        Sebastian added a comment -

        Is this JIRA about extending the event mechanism introduced with WICKET-1312 or implementing a completely new one? If the latter is the case is it supposed to replace WICKET-1312 or coexist with it? I'd like to see only a single event API in Wicket.

        Show
        Sebastian added a comment - Is this JIRA about extending the event mechanism introduced with WICKET-1312 or implementing a completely new one? If the latter is the case is it supposed to replace WICKET-1312 or coexist with it? I'd like to see only a single event API in Wicket.
        Hide
        James Carman added a comment -

        We may also need to introduce the concept of a "chain" here (like we had in HiveMind). Basically, a "chain" would allow you to have non-void return types. We return the first non-default return value from the items in the chain. So, the exception handling stuff would be a chain, since we have to get an IRequestHandler return value.

        Show
        James Carman added a comment - We may also need to introduce the concept of a "chain" here (like we had in HiveMind). Basically, a "chain" would allow you to have non-void return types. We return the first non-default return value from the items in the chain. So, the exception handling stuff would be a chain, since we have to get an IRequestHandler return value.
        Hide
        James Carman added a comment -

        The proxy stuff isn't really that bad in this case. The proxies aren't used to do drastic, crazy logic. All they're used for is to dispatch the events to all registered listeners, allowing you to merely call the listener method you want with the arguments you want and it will be multicast out to all of the registered listeners.

        As for the unregister part, I don't really see where you would need to unregister these types of listeners. This is for application-level, cross-cutting concerns, basically all of the "hooks" where plugin/framework developers would need to be able to integrate. Right now, this is very difficult because you have to override factory methods or (with providers) do some sort of wrapping/decorating to allow more than one framework to join in.

        Show
        James Carman added a comment - The proxy stuff isn't really that bad in this case. The proxies aren't used to do drastic, crazy logic. All they're used for is to dispatch the events to all registered listeners, allowing you to merely call the listener method you want with the arguments you want and it will be multicast out to all of the registered listeners. As for the unregister part, I don't really see where you would need to unregister these types of listeners. This is for application-level, cross-cutting concerns, basically all of the "hooks" where plugin/framework developers would need to be able to integrate. Right now, this is very difficult because you have to override factory methods or (with providers) do some sort of wrapping/decorating to allow more than one framework to join in.
        Hide
        Rodolfo Hansen added a comment -

        To me, this is a more radical and over-arching change than WICKET-1312
        It seems to be meant as an alternative of how the extension points are offered to framework developers... So projects like wiquery, databinder and spring can co-exist with less hassle..

        Show
        Rodolfo Hansen added a comment - To me, this is a more radical and over-arching change than WICKET-1312 It seems to be meant as an alternative of how the extension points are offered to framework developers... So projects like wiquery, databinder and spring can co-exist with less hassle..
        Hide
        Martin Grigorov added a comment -

        Oh, I believed this ticket is created by Rodolfo ...
        James, you already know about this ...

        Show
        Martin Grigorov added a comment - Oh, I believed this ticket is created by Rodolfo ... James, you already know about this ...
        Hide
        Martin Grigorov added a comment -

        This was discussed the day before yesterday in IRC between Igor Vaynberg and James Carman.
        James said there is exactly the same functionality in commons-lang: listener + proxy based dispatcher.
        Igor had concerns for both points:

        • proxy - hard to debug
        • listener - you need to unregister the listener when its sink or target gets removed

        Currently there is a similar functionality in 1.5: org.apache.wicket.IEventDispatcher.dispatchEvent(IEventSink, IEvent<?>). See WICKET-1312 for more details.

        Show
        Martin Grigorov added a comment - This was discussed the day before yesterday in IRC between Igor Vaynberg and James Carman. James said there is exactly the same functionality in commons-lang: listener + proxy based dispatcher. Igor had concerns for both points: proxy - hard to debug listener - you need to unregister the listener when its sink or target gets removed Currently there is a similar functionality in 1.5: org.apache.wicket.IEventDispatcher.dispatchEvent(IEventSink, IEvent<?>). See WICKET-1312 for more details.
        Hide
        Rodolfo Hansen added a comment -

        This seems like a very good idea,

        I would like to see the components messaging and wicket-push take this into account.

        I am very interested in seeing how this develops.

        Show
        Rodolfo Hansen added a comment - This seems like a very good idea, I would like to see the components messaging and wicket-push take this into account. I am very interested in seeing how this develops.

          People

          • Assignee:
            Unassigned
            Reporter:
            James Carman
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development