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.

I just wouldn't want to have a single magic custom event that handles almost everything.

ECA doesn't really have a contextual validation logic anyway, so I'm wondering why we'd suddenly want to do this for custom events.

The difference between a "Custom Event" and "Custom Event (entity-aware)" is still a confusing concept. In that particular example the entity-aware even makes barely sense anymore since we support forwarding tokens anyway. We'd also then need to implement one action for each for being able to trigger it. I've had received many problem reports as the configuration was using an entity-aware custom event but was using eca_base's "Trigger custom event" (->not entity-aware) action to trigger it, which doesn't work.

Agreed, we've seen such issues before too. If we put support for all kind of context into one custom event, that event should be able to handle explicit objects like render arrays, access results, maybe http responses, and more. It should also implement quite a few interfaces. That way, action that only work within specific contexts (e.g. render actions) would still recognize that the triggering event is render aware and they would just apply their results to that event, which then has to pass that upstream when finished.

That would be the most user-friendly solution, but the event would need to be aware of quite a few interfaces from ECA submodules. But that's probably solvable.