Make custom events re-usable for rendering and other event types

This is an interesting thought. However, we've achieved re-usable render components by adding them to tokens and then add those tokens to the render array. Or in other use case, e.g. for views fields or extra fields on entities, we've just started with multiple events leading to the same render actions to provide the same field for multiple use cases.

Of course, making this even more convenient is a good thing. Maybe even with a "Custom render event"?

While the render example was the first reason I thought of making custom events "more reusable", this actually applies also to other sorts of events, such as access. So currently I cannot properly execute "Set access result" within a custom event.

But it could be argued, whether a custom event should be only supporting one sort of "return type" which are currently tokens. At the same time some custom events may just fulfill for one specific purpose, such as rendering something or setting a specific result.

By the way, we're currently using an "advanced" implementation of the custom event to support renaming of tokens being passed along, by setting "from_name->to_name" pattern in the field for tokens to forward. We often have cases where for example a custom event accepts a "node" token, whereas the calling parent process is working with multiple nodes having different names in context. The renaming is convenient in such cases. If you're interested in that I can create another issue for it.

Yeah, I'm not against more custom events. I just wouldn't want to have a single magic custom event that handles almost everything. Instead, a custom event in eca_render, another one in eca_access, and even others in certain context where required. So, the model would then have to choose the appropriate custom event which allows them to do whatever they need.

When it comes to more sophisticated token forwarding, I also had that requirement recently. A pretty simple approach could be to allow the text field, which currently accepts a comma separated list of token names, to use yaml. That way, any number of tokens can be forwarded, similar to named arguments in a function call. Example:

my_entity: current_group
my_user: attendee
my_email: email

The custom event would receive tokens with the names my_entity, my_user, and my_email. The values in those tokens would be the named tokens on the right, which need to be present in the context of the calling action.

This way, the same custom event can be called from different places. The tokens in the calling context can be named anything, the names in the custom event would always be the same. This should be diverted to a separate issue, though.