You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "James Carman (JIRA)" <ji...@apache.org> on 2010/12/19 08:00:00 UTC
[jira] Created: (WICKET-3274) Application-Scoped EventBus
Application-Scoped EventBus
---------------------------
Key: WICKET-3274
URL: https://issues.apache.org/jira/browse/WICKET-3274
Project: Wicket
Issue Type: New Feature
Components: wicket
Affects Versions: 1.5-M3
Reporter: James Carman
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "James Carman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973030#action_12973030 ]
James Carman commented on WICKET-3274:
--------------------------------------
Agreed
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "Sebastian (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972994#action_12972994 ]
Sebastian commented on WICKET-3274:
-----------------------------------
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.
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "Sebastian (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973029#action_12973029 ]
Sebastian commented on WICKET-3274:
-----------------------------------
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.
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972934#action_12972934 ]
Martin Grigorov commented on WICKET-3274:
-----------------------------------------
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.
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "James Carman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972985#action_12972985 ]
James Carman commented on WICKET-3274:
--------------------------------------
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.
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "Rodolfo Hansen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972946#action_12972946 ]
Rodolfo Hansen commented on WICKET-3274:
----------------------------------------
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..
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "Rodolfo Hansen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972928#action_12972928 ]
Rodolfo Hansen commented on WICKET-3274:
----------------------------------------
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.
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] [Resolved] (WICKET-3274) Application-Scoped EventBus
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov resolved WICKET-3274.
-------------------------------------
Resolution: Later
Closing the ticket.
It seems the current Event system works well for now. There are no complaints in Jira and mailing lists
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972935#action_12972935 ]
Martin Grigorov commented on WICKET-3274:
-----------------------------------------
Oh, I believed this ticket is created by Rodolfo ...
James, you already know about this ...
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "James Carman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972992#action_12972992 ]
James Carman commented on WICKET-3274:
--------------------------------------
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.
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
Posted by "James Carman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972997#action_12972997 ]
James Carman commented on WICKET-3274:
--------------------------------------
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.
> Application-Scoped EventBus
> ---------------------------
>
> Key: WICKET-3274
> URL: https://issues.apache.org/jira/browse/WICKET-3274
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M3
> Reporter: James Carman
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.