Question

I have been using the pico container in java to do DI for a minecraft plugin framework I designed.

The plugins have event listener methods that are defined in interfaces, one method per interface.

If a particular class wants events when players join and leave the server, it implements the two particular interfaces; in this case IPlayerLoginEvent and IPlayerQuitEvent.

I then have a class in the frameworks which takes each type of event interface as a constructor injected argument.

This container class is tagged with @Listener for the craftbukkit server software to call it.

The wrapper class wraps the data craftbukkit sends in with a framework-specific class, making it possible, at least in theory, to write server-agnostic plugins.

Small example:

The plugin AwesomePlugin has a class PlayerHandler which implements IPlayerLoginEvent and IPlayerQuitEvent. The framework needs then to construct instances of each of the classes “PlayerLogin” and “PlayerQuit”, passing in the PlayerHandler as a constructor argument.
The PlayerLogin and PlayerQuit instances will in turn be registered with CraftBukkit as event listeners.

The way this is currently implemented using pico, can be seen here:

https://github.com/Runsafe/Framework/blob/master/src/no/runsafe/framework/event/EventEngine.java#L32

That code does look terrible and I have not been able to find a more elegant solution for this scenario, so I now beseech your guidance 🙂

Answer 1

Well, I don’t quite understand you question but I can explain some pico events patterns.

First of all, events are container-centric, you don’t use pico just to wire things up.
Every event consumer is added to the container. Each consumer has to implement at least one method to get event obj. You can have single interface with generic Event class passed, or you can have many interfaces for different event types.

Thus, you have a list of consumers in the container (or several lists for several event types) You can either have the list of consumers injected into some event broadcaster object (obviously done once per container creation, the broadcaster receives the event somehow from somewhere, then just iterates through the list and calls relevant event handler methods) or just make a container custom lifecycle call (can be done anytime and trigger consumers added in runtime, the calling job is done by the container itself)

Sometimes you may even want to create new event-container for each event, adding the event obj and all the relevant consumers.

Waffle framework contains the nicest examples of pico containers juggling, events handling etc.