Using order and priority for event listeners about spongeapi HOT 6 CLOSED

@EnderEli 👍

from spongeapi.

The given approach in this ticket would equal adding more levels of Order (and organizing them slightly differently)?
....
A slightly different approach has been discussed by some pe ople on the first commit:
5a96c64#commitcomment-7695983

It boiled down to have the Order more or less as is and add a way to relate to other listeners for the level of Order you registered for. Specifically a listener (method) has three additional properties for the event handler annotation:

1. tags which describe the listener (e.g. net.abc.PluginXY, net.abc.PluginXY.Feature123, WORLD_PROTECTION)
2. • 3. "before" and "after", which both describe a set of regex or just tags to be registered before or after, also allowing to register before or after all others (e.g. before = {"*"}.

This way you can relate to other plugin on the same level of Order. This approach focuses on the aspect of cross-plugin compatibility, usually knowing the plugins you relate to, though establishing generic tags (like WORLD_PROTECTION, SECURITY) could help for some cases too.

Not sure this should be discussed here, though.

from spongeapi.

@EnderEli 👍 I really do like that idea, but I am not sure if others do ;)

from spongeapi.

@asofold But I think it is the easiest general system. I will link it to the commit so everyone can says what he thinks.

I can create a global API commit so we can look at it.

from spongeapi.

@EnderEli Actually i don't know if the Sponge team wants to have stuff discussed independently, in that case i would have to start a competing ticket :p. I think it needs be considered to weigh out these approaches, not because the do the same thing, but because they are slightly opposing in nature, not impossible to both exist alongside, but it would then mean using 3 things of order/priority, which seems... a lot.

So if i understand this right, your approach simplifies the top level, while increasing the total number of levels, roughly staying equivalent to the original commit (splitting levels by a finite number is the same as adding more levels, except for the usability/appearance). On a side note, you will certainly need the sub-priorities on pre/post levels, they still are crucial to some cross-plugin compatibility scenarios.

It's hard to tell ad hoc, what the typical situation will be with many plugins registred, but this could also do the trick for most things, though it changes the easy to overlook Order vs. a two-layered system that does not allow relating to specific other plugins, for the case of cross-plugin compatibility being the objective.

from spongeapi.

@asofold

Yes and no. The basic idea, going to the roots, is splitting the listener orders in two parts. The access level, so read only, cancelable, read only end....
And then the priority, where we can use a basic system OR dependencies like "after WorldGuard"...

So the developer can set the acces level and then a priority or an order related to 3rd party plugins...

from spongeapi.