Interesting idea.  I implemented this such that the event dispatcher checks
if the result of invoking the event handler method returns an object of
type Visit.  It then uses the Visit object to figure out what to do and how
to manipulate the IEvent object.  So, the stop property is still available
in case you know what you want to do at compile time; the Visit return
object is there for determining what to do at run-time.  Of course, you
could also always simply fallback to overriding the onEvent method.

Andrew


On Thu, Jun 5, 2014 at 3:12 AM, Martin Grigorov <notifications@github.com>
wrote:

> In
> jdk-1.7-parent/annotationeventdispatcher-parent/annotationeventdispatcher/src/main/java/org/wicketstuff/event/annotation/AnnotationEventSink.java:
>
> >  	{
> >  		try
> >  		{
> >  			for (Method method : onEventMethods)
> >  			{
> > -				method.invoke(sink, payload);
> > +				OnEvent onEvent = method.getAnnotation(OnEvent.class);
> > +				if (isPayloadApplicableToHandler(onEvent, payload))
> > +				{
> > +					method.invoke(sink, payload);
> > +					if (onEvent.stop()) {
>
> This is not very flexible. But I understand this is the only way with
> annotations.
>
> Maybe the method's return type could be something different than Void.
> Then you can use it to decide what to do.
> As with Wicket's visitors - stop, continue, continueDontGoDeeper.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/wicketstuff/core/pull/309/files#r13426705>.
>