Define Priority and Polymorphism at Listener Level #10

New Issue

kske · 2021-02-20T22:04:06+01:00

kske commented

2021-02-20 22:04:06 +01:00

In common use cases, the event handlers inside a listener have the same priority, and in some cases are all polymorphic.

Instead of defining this per-handler and possibly mistyping a priority or forgetting an annotation, @Priority and @Polymorphic could be allowed at a class level and thus per-listener.

The handler properties defined at a listener level would then be used by handlers without explicit definitions.

To allow the negation of listener-level polymorphy on a single handler, @Polymorphic should be extended with a boolean value that defaults to true.

In common use cases, the event handlers inside a listener have the same priority, and in some cases are all polymorphic. Instead of defining this per-handler and possibly mistyping a priority or forgetting an annotation, `@Priority` and `@Polymorphic` could be allowed at a class level and thus per-listener. The handler properties defined at a listener level would then be used by handlers without explicit definitions. To allow the negation of listener-level polymorphy on a single handler, `@Polymorphic` should be extended with a boolean value that defaults to `true`.

kske added the

enhancement

label 2021-02-20 22:04:06 +01:00

kske self-assigned this 2021-02-20 22:04:06 +01:00

kske added the

core

proc

labels 2021-02-20 22:21:36 +01:00

kske referenced a pull request that will close this issue

2021-03-14 11:19:15 +01:00

Listener-Level Properties #13

kske added the