You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Ernesto Reinaldo Barreiro <re...@gmail.com> on 2013/06/01 05:54:15 UTC
Re: reworking events to be type safe for Wicket 7.
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 <mg...@apache.org>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
Re: reworking events to be type safe for Wicket 7.
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Thansk! I will have a look.
On Mon, Jun 3, 2013 at 4:36 PM, Edvard Fonsell <
edvard.fonsell@nitorcreations.com> wrote:
> Hello,
>
> We have implemented an annotation based solution to avoid the type safety
> / instanceof problem with the events. Instead of
>
>
> @Override
> public void onEvent(IEvent<?> event) {
> Object payload = event.getPayload();
> if (payload instanceof FirstEvent) {
> payload.doSomething();
> } else if (payload instanceof SecondEvent) {
> payload.doSomethingElse();
> }
> }
>
> you can do
>
> @OnEvent
> public void onEvent(FirstEvent event) {
> event.doSomething();
> }
>
> @OnEvent
> public void onEvent(SecondEvent event) {
> event.doSomethingElse();
> }
>
> The implementation is available here:
>
> https://github.com/**NitorCreations/wicket<https://github.com/NitorCreations/wicket>
>
> To use this event dispatcher, you need to have this in your application
> initialization:
>
> AnnotationEventDispatcher dispatcher = new AnnotationEventDispatcher();
> getComponentInstantiationListe**ners().add(dispatcher);
> getFrameworkSettings().add(**dispatcher);
>
> To minimize the performance impact, the annotated methods are scanned only
> once per component class (when the first component of that class is
> instantiated). Also the annotated methods for the component class to be
> called for a certain event payload type are resolved only once (when the
> first event of that type is dispatched for the component type).
>
> To enhance this further, we have been thinking about making the current
> event handling optional to avoid calling the empty Component.onEvent for
> each and every event. However, there is currently no support for annotated
> methods in Behaviors etc., only in Components.
>
> Best Regards,
>
> Edvard
>
> p.s. This works in Wicket 6 as well.
>
>
> On 01.06.2013 06:54, Ernesto Reinaldo Barreiro wrote:
>
>> 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 <mgrigorov@apache.org
>> >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
>>
>>
> --
> Edvard Fonsell
> edvard.fonsell@nitorcreations.**com <ed...@nitorcreations.com>
> +358(0)40 722 7554
>
--
Regards - Ernesto Reinaldo Barreiro
Re: reworking events to be type safe for Wicket 7.
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sat, Oct 12, 2013 at 3:24 AM, eloyArce <el...@yahoo.com.ar> wrote:
> Hi,
>
> I've tried version 6.9.0, and it is really what I was looking for. But i'm
> having trouble to use it in anonymous inner classes (very common in wicket)
> like the one in the your TestCase.
>
> The problem is that reflection can't invoke methods on anonymous inner
> classes, unless the containing class is in the same package that the one
> that is using reflection (AnnotationEventSink in this case)
>
> Thet TestCase works great because AnnotationEventDispatcherTest is in the
> package org.wicketstuff.event.annotation (like AnnotationEventSink )
>
> Do you think it is possible to resolve this without using
> /method/.setAccessible(true) ?
> (that approach may not work if a SecurityManager is in place)
>
Please create a ticket at https://github.com/wicketstuff/core/issues.
A test case would help a lot.
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/reworking-events-to-be-type-safe-for-Wicket-7-tp4659155p4661802.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>
Re: reworking events to be type safe for Wicket 7.
Posted by eloyArce <el...@yahoo.com.ar>.
Hi,
I've tried version 6.9.0, and it is really what I was looking for. But i'm
having trouble to use it in anonymous inner classes (very common in wicket)
like the one in the your TestCase.
The problem is that reflection can't invoke methods on anonymous inner
classes, unless the containing class is in the same package that the one
that is using reflection (AnnotationEventSink in this case)
Thet TestCase works great because AnnotationEventDispatcherTest is in the
package org.wicketstuff.event.annotation (like AnnotationEventSink )
Do you think it is possible to resolve this without using
/method/.setAccessible(true) ?
(that approach may not work if a SecurityManager is in place)
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/reworking-events-to-be-type-safe-for-Wicket-7-tp4659155p4661802.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: reworking events to be type safe for Wicket 7.
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
The code looks really good! I hope to use it soon.
I've added IInitializer that configures the application automatically when
this jar is in the classpath.
On Tue, Jun 11, 2013 at 12:52 PM, harmoniaa <
edvard.fonsell@nitorcreations.com> wrote:
> Here it is:
>
>
> https://github.com/wicketstuff/core/commit/f98007825c6c4f97d33540a2e7edb8fc356a5644
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/reworking-events-to-be-type-safe-for-Wicket-7-tp4659155p4659376.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>
Re: reworking events to be type safe for Wicket 7.
Posted by harmoniaa <ed...@nitorcreations.com>.
Here it is:
https://github.com/wicketstuff/core/commit/f98007825c6c4f97d33540a2e7edb8fc356a5644
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/reworking-events-to-be-type-safe-for-Wicket-7-tp4659155p4659376.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: reworking events to be type safe for Wicket 7.
Posted by Martin Grigorov <mg...@apache.org>.
Hi Edvard,
Tell me your github username and I'll add you to WicketStuff collaborators
team so you can push there.
I'll try to help and Ernesto already offered his help.
On Mon, Jun 10, 2013 at 2:36 PM, harmoniaa <
edvard.fonsell@nitorcreations.com> wrote:
> There was no reason to change Wicket's code directly, creating a project in
> WicketStuff sounds like a good idea. And all help is welcome!
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/reworking-events-to-be-type-safe-for-Wicket-7-tp4659155p4659340.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>
Re: reworking events to be type safe for Wicket 7.
Posted by harmoniaa <ed...@nitorcreations.com>.
There was no reason to change Wicket's code directly, creating a project in
WicketStuff sounds like a good idea. And all help is welcome!
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/reworking-events-to-be-type-safe-for-Wicket-7-tp4659155p4659340.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: reworking events to be type safe for Wicket 7.
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
+1...
I'm willing to help with this.
On Mon, Jun 10, 2013 at 12:59 PM, Martin Grigorov <mg...@apache.org>wrote:
> Hi Edvard,
>
> Thank you for sharing your work!
>
> Is there any reason why you change Wicket's code directly (i.e. you have a
> custom build of Wicket) instead of creating a separate library jar ?
> Since several users have asked for this functionality I think we can create
> a project in WicketStuff and make it stable. Then we can even move it to
> wicket-(core|extensions) when we are happy with the implementation.
>
> Do you like this idea ?
>
>
> On Mon, Jun 3, 2013 at 3:36 PM, Edvard Fonsell <
> edvard.fonsell@nitorcreations.com> wrote:
>
> > Hello,
> >
> > We have implemented an annotation based solution to avoid the type safety
> > / instanceof problem with the events. Instead of
> >
> >
> > @Override
> > public void onEvent(IEvent<?> event) {
> > Object payload = event.getPayload();
> > if (payload instanceof FirstEvent) {
> > payload.doSomething();
> > } else if (payload instanceof SecondEvent) {
> > payload.doSomethingElse();
> > }
> > }
> >
> > you can do
> >
> > @OnEvent
> > public void onEvent(FirstEvent event) {
> > event.doSomething();
> > }
> >
> > @OnEvent
> > public void onEvent(SecondEvent event) {
> > event.doSomethingElse();
> > }
> >
> > The implementation is available here:
> >
> > https://github.com/**NitorCreations/wicket<
> https://github.com/NitorCreations/wicket>
> >
> > To use this event dispatcher, you need to have this in your application
> > initialization:
> >
> > AnnotationEventDispatcher dispatcher = new AnnotationEventDispatcher();
> > getComponentInstantiationListe**ners().add(dispatcher);
> > getFrameworkSettings().add(**dispatcher);
> >
> > To minimize the performance impact, the annotated methods are scanned
> only
> > once per component class (when the first component of that class is
> > instantiated). Also the annotated methods for the component class to be
> > called for a certain event payload type are resolved only once (when the
> > first event of that type is dispatched for the component type).
> >
> > To enhance this further, we have been thinking about making the current
> > event handling optional to avoid calling the empty Component.onEvent for
> > each and every event. However, there is currently no support for
> annotated
> > methods in Behaviors etc., only in Components.
> >
> > Best Regards,
> >
> > Edvard
> >
> > p.s. This works in Wicket 6 as well.
> >
> >
> > On 01.06.2013 06:54, Ernesto Reinaldo Barreiro wrote:
> >
> >> 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 <mgrigorov@apache.org
> >> >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
> >>
> >>
> > --
> > Edvard Fonsell
> > edvard.fonsell@nitorcreations.**com <ed...@nitorcreations.com>
> > +358(0)40 722 7554
> >
>
--
Regards - Ernesto Reinaldo Barreiro
Re: reworking events to be type safe for Wicket 7.
Posted by Martin Grigorov <mg...@apache.org>.
Hi Edvard,
Thank you for sharing your work!
Is there any reason why you change Wicket's code directly (i.e. you have a
custom build of Wicket) instead of creating a separate library jar ?
Since several users have asked for this functionality I think we can create
a project in WicketStuff and make it stable. Then we can even move it to
wicket-(core|extensions) when we are happy with the implementation.
Do you like this idea ?
On Mon, Jun 3, 2013 at 3:36 PM, Edvard Fonsell <
edvard.fonsell@nitorcreations.com> wrote:
> Hello,
>
> We have implemented an annotation based solution to avoid the type safety
> / instanceof problem with the events. Instead of
>
>
> @Override
> public void onEvent(IEvent<?> event) {
> Object payload = event.getPayload();
> if (payload instanceof FirstEvent) {
> payload.doSomething();
> } else if (payload instanceof SecondEvent) {
> payload.doSomethingElse();
> }
> }
>
> you can do
>
> @OnEvent
> public void onEvent(FirstEvent event) {
> event.doSomething();
> }
>
> @OnEvent
> public void onEvent(SecondEvent event) {
> event.doSomethingElse();
> }
>
> The implementation is available here:
>
> https://github.com/**NitorCreations/wicket<https://github.com/NitorCreations/wicket>
>
> To use this event dispatcher, you need to have this in your application
> initialization:
>
> AnnotationEventDispatcher dispatcher = new AnnotationEventDispatcher();
> getComponentInstantiationListe**ners().add(dispatcher);
> getFrameworkSettings().add(**dispatcher);
>
> To minimize the performance impact, the annotated methods are scanned only
> once per component class (when the first component of that class is
> instantiated). Also the annotated methods for the component class to be
> called for a certain event payload type are resolved only once (when the
> first event of that type is dispatched for the component type).
>
> To enhance this further, we have been thinking about making the current
> event handling optional to avoid calling the empty Component.onEvent for
> each and every event. However, there is currently no support for annotated
> methods in Behaviors etc., only in Components.
>
> Best Regards,
>
> Edvard
>
> p.s. This works in Wicket 6 as well.
>
>
> On 01.06.2013 06:54, Ernesto Reinaldo Barreiro wrote:
>
>> 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 <mgrigorov@apache.org
>> >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
>>
>>
> --
> Edvard Fonsell
> edvard.fonsell@nitorcreations.**com <ed...@nitorcreations.com>
> +358(0)40 722 7554
>
Re: reworking events to be type safe for Wicket 7.
Posted by Edvard Fonsell <ed...@nitorcreations.com>.
Hello,
We have implemented an annotation based solution to avoid the type
safety / instanceof problem with the events. Instead of
@Override
public void onEvent(IEvent<?> event) {
Object payload = event.getPayload();
if (payload instanceof FirstEvent) {
payload.doSomething();
} else if (payload instanceof SecondEvent) {
payload.doSomethingElse();
}
}
you can do
@OnEvent
public void onEvent(FirstEvent event) {
event.doSomething();
}
@OnEvent
public void onEvent(SecondEvent event) {
event.doSomethingElse();
}
The implementation is available here:
https://github.com/NitorCreations/wicket
To use this event dispatcher, you need to have this in your application
initialization:
AnnotationEventDispatcher dispatcher = new AnnotationEventDispatcher();
getComponentInstantiationListeners().add(dispatcher);
getFrameworkSettings().add(dispatcher);
To minimize the performance impact, the annotated methods are scanned
only once per component class (when the first component of that class is
instantiated). Also the annotated methods for the component class to be
called for a certain event payload type are resolved only once (when the
first event of that type is dispatched for the component type).
To enhance this further, we have been thinking about making the current
event handling optional to avoid calling the empty Component.onEvent for
each and every event. However, there is currently no support for
annotated methods in Behaviors etc., only in Components.
Best Regards,
Edvard
p.s. This works in Wicket 6 as well.
On 01.06.2013 06:54, Ernesto Reinaldo Barreiro wrote:
> 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 <mg...@apache.org>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
>
--
Edvard Fonsell
edvard.fonsell@nitorcreations.com
+358(0)40 722 7554