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