Hi Martin, Thank you very much for your answer and apologies for my late reply.
On Thu, May 30, 2013 at 11:32 AM, Martin Grigorov <[email protected]>wrote: > Hi Ernesto, > > With the current API I'd do it : > > @Override > public void onEvent(IEvent<?> event) { > Object payload = event.getPayload(); > if (payload instanceof FirstEvent) { > handle((FirstEvent) payload); > } else if (payload instanceof AnotherEvent) { > handle((AnotherEvent) payload); > } > ... > } > > private void handle(FirstEvent) { ... } > private void handle(AnotherEvent) { ... } > > It is fairly clean. > That's what I wanted to avoid... I would like "someone" to take care of this plumbing for me. > > > With IFrameworkSettings#add(IEventDispatcher) this logic can be generalized > even more. > For example: > > @EventCallback // custom annotation > private void handle(FirstEvent) {...} > > i.e. use reflection to find all annotated methods which accept the type of > the event as parameter. > > See org.apache.wicket.EventDispatcherTest#dispatchToAnnotatedMethod() in > wicket-core unit tests for a simple implementation. > A more robust impl should cache the results of the reflection > introspections. > Yes I was aware you can plug you own event delivery machinery.... I think I will explore the "reflection based approach" either with annotations or using some convention on methods' names. I'm using events mostly at panel level. So, it might make much sense to roll my own "EventedPanel" and inherit form it... than hooking into global settings. I will play with both and decide which way I go. Thanks again for your support! Cheers, Ernesto Reinaldo Barreiro
