Poll for new feature

[Jeff Larsen]

One thing that I know I would find very useful for various aspects is
having the ability to create a true 1-N relationship between the
eventbus and the events that implement it. Some discussion has already
gone on here http://code.google.com/p/mvp4g/issues/detail?id=42

But I'll summarize the discussion here. It would be a huge help to be
able to do an event annotation the following way


@Events(....)
public interface SomeEventBus extends EventBus{


@Event(implementedBy=SomeInterface.class)
void someEvent(...);

}

public interface SomeInterface extends MarkerInterface {

void onSomeEvent(...);

}

@Presenter(...)
public Presenter1 extends BasePresenter<....> implements
SomeInterface{
....

public void onSomeEvent(...)

}

@Presenter(...)
public Presenter2 extends BasePresenter<....> implements
SomeInterface{

....

public void onSomeEvent(...)

}

@EventHandler(...)
public EventHandler extends BasePresenter<....> implements
SomeInterface{
....

public void onSomeEvent(...){

}


This will allow you to have an event to be able to be handled by many
presenters without having to go back and edit the eventbus for each
presenter and for events that have a lot of handlers, the eventbus
will become more readable.

[Dennis]

one thing that comes to my mind: This will make it even more difficult
to track the event flow (who handles what), as you need to first open
the event bus, then open the interface class, and then see who
inherits from it to get all handlers/presenters (usually with help
from the IDE).
What I like about the current event bus is that it all comes together
here, you can see in one single place who handles what. Otherwise
things will be even more spread out and harder to reason about it.
Maybe I just never had so many handlers for a single event that it
posed a problem for me....

On Oct 5, 4:37 pm, Jeff Larsen <larse...@gmail.com> wrote:
> One thing that I know I would find very useful for various aspects is
> having the ability to create a true 1-N relationship between the
> eventbus and the events that implement it. Some discussion has already

> gone on herehttp://code.google.com/p/mvp4g/issues/detail?id=42

[Jeff Larsen]

In eclipse you can do a ctrl-t on the interface right in the eventbus
to find out all the classes that implement it.

On Oct 5, 12:42 pm, Dennis <googelyb...@gmail.com> wrote:
> one thing that comes to my mind: This will make it even more difficult
> to track the event flow (who handles what), as you need to first open
> the event bus, then open the interface class, and then see who
> inherits from it to get all handlers/presenters (usually with help
> from the IDE).

In eclipse you can do a ctrl-t on the interface right in the eventbus
to find out all the classes that implement it. That being said, no one
would force you to use this. For my usecase this is pretty much
mission critical.

> What I like about the current event bus is that it all comes together
> here, you can see in one single place who handles what. Otherwise
> things will be even more spread out and harder to reason about it.
> Maybe I just never had so many handlers for a single event that it
> posed a problem for me....

My problem is I need to allow for people to extend my framework and
add additional components to listen for events. What I write and give
to a group of developers should be able to be extended just by adding
files to the classpath and should not require that they manually edit
my source, otherwise upgrades to the framework will become a giant
pain.

[Pierre]

For regular events (ie with only a few presenters), I agree with
Dennis. I'd rather configure it thanks to the event bus to easily
control the event flow.

However this feature could be really useful in the case described by
Jeff (where you want to add other handlers without modifying the event
bus) and also if you want to broadcast an event to a lot of handlers.
We could also extend this feature to child module: if a child module
extends the interface, then the event will be automatically forwarded
to it:

@Events(....)
@ChildModules(@ChildModule(moduleClass=SomeChildModule.class),...)

public interface SomeEventBus extends EventBus{

@Event(implementedBy=SomeInterface.class)
void someEvent(...);

}

public interface SomeInterface {
//I don't think it's necessary to define the handling method here
since the framework will verify that each handler defines the right
method
//at compilation time. Also without this method, we can extend it to
child module
}

public interface SomeChildModule extends Mvp4gModule, SomeInterface {
//this mean that SomeChildModule will need an event bus with the
someEvent method
}

What do you think?

Thanks,
Pierre

ps: like for any new feature, don't hesitate to star it to prioritize
it. Also any help is appreciated so if you ever come up with a patch
to fix this issue, let me know. Thanks.

> > > will become more readable.- Hide quoted text -
>
> - Show quoted text -

[Jeff Larsen]

On Oct 6, 7:03 am, Pierre <plcoir...@gmail.com> wrote:
> For regular events (ie with only a few presenters), I agree with
> Dennis. I'd rather configure it thanks to the event bus to easily
> control the event flow.
>
> However this feature could be really useful in the case described by
> Jeff (where you want to add other handlers without modifying the event
> bus) and also if you want to broadcast an event to a lot of handlers.
> We could also extend this feature to child module: if a child module
> extends the interface, then the event will be automatically forwarded
> to it:
>
> @Events(....)
> @ChildModules(@ChildModule(moduleClass=SomeChildModule.class),...)
> public interface SomeEventBus extends EventBus{
>
>    @Event(implementedBy=SomeInterface.class)
>    void someEvent(...);
>
> }
>
> public interface SomeInterface {
> //I don't think it's necessary to define the handling method here
> since the framework will verify that each handler defines the right
> method
> //at compilation time. Also without this method, we can extend it to
> child module
>
> }

Yea, adding the method to the interface wouldn't be required.

>
> public interface SomeChildModule extends Mvp4gModule, SomeInterface {
> //this mean that SomeChildModule will need an event bus with the
> someEvent method
>
> }
>
> What do you think?
>
> Thanks,
> Pierre
>
> ps: like for any new feature, don't hesitate to star it to prioritize
> it. Also any help is appreciated so if you ever come up with a patch
> to fix this issue, let me know. Thanks.

I have taken some time and dug into the code you've written for the
other annotations, and I think I'm starting to understand what it is
doing. I can probably take a stab at implementing something, but I
moved just this past weekend, so my free time will be minimal for the
next few weeks at best.

[Pierre]

> I have taken some time and dug into the code you've written for the
> other annotations, and I think I'm starting to understand what it is
> doing. I can probably take a stab at implementing something, but I
> moved just this past weekend, so my free time will be minimal for the
> next few weeks at best.

Thanks I appreciate any help. If you have any question, let me know.
Also if you don't have time, I will add it to my todo list but I want
to integrate other features first (above all navigation confirmation).

Thanks,
Pierre