Allow GenericEventSubscriber::onRulesEvent to extract contexts via Event getters

I had the same problem. This patch solved it.

Hi,
The patch worked for me but with a small modification. The getter method it's not called as a method, but as property. Shouldn't be like in the interdiff attached?

Thanks, the patch looks good. A remark though:

+++ b/src/EventSubscriber/GenericEventSubscriber.php
@@ -112,15 +112,23 @@ class GenericEventSubscriber implements EventSubscriberInterface {
+      elseif (isset($event->{lcfirst(ucwords($context_name, '_'))})) {

I do not think we should do magic conversion of the context name for variables. Either it fits, or you have to use the method.

I created a less complex patch.

Hi,

My suggestion is to allow a "getter" property to be provided in the YAML like so:

my_module.example:
  label: 'After something happens'
  category: 'Example'
  context:
    user:
      type: 'entity:user'
      label: 'User'
      getter: 'loadUser'

We could still check if a method with the standard name exists when this property is missing, but I think explicitly providing the method makes it much more flexible - one wouldn't have to wrap a third-party event just because it did not follow naming conventions.

It also has the advantage of decoupling the name exposed to data selection ("user" in this example) from the Event's class implementation (the method name). This would be useful in cases the getter has a generic name like "getEntity" as in the example below:

my_module.other_example:
  label: 'After something else happens'
  category: 'Example'
  context:
    article:
      type: 'entity:node'
      label: 'Article'
      getter: 'getEntity'

@dbiscalchin: I think that sounds like a good idea. IMO it has advantages over what has been proposed earlier in this thread, and like you said it affords much more flexibility in how event classes work. Additionally, because the means of accessing a context variable would be part of the plugin definition, it could be altered using the plugin manager's hook_rules_event_alter().

Can you create a patch to do this?

I think this is very important for integration with contributed modules, where event properties tend to be protected so we currently can't just add the .yml and make use of those events.

This patch implements the idea from #13.

Additionally, this patch allows access to Event properties when those properties are declared as protected or private - this has always been a problem that prevented Rules from making use of Events defined by other modules, because most Event objects don't use public visibility for their properties.

And of course, tests are included to ensure this works.

Event properties are accessed as follows:

1. Rules will first use the getter method if it is defined in the MODULE.rules.events.yml file. This allows overriding the default behavior.
2. If there is no getter, Rules will check the Event class to see if it is a subclass of GenericEvent. If so, Rules can access the property values through the getArguments() method.
3. Finally, if there is no getter method and the Event is not a GenericEvent, Rules will peek into the class and access the properties by name, regardless of whether they are public, protected, or private.

This should finally allow us to use any third-party event directly from Rules, simply by adding the necessary metadata into a MODULE.rules.events.yml file.

Remove commented out code and clean up coding standards.

Some more coding standards, fix plugin discovery in Unit tests (hopefully).

Added a bunch of comments.

Also re-wrote the issue summary.

The patch in #22 adds to the 8 branch failures in the D10 tests (see #3259445: Symfony\Component\EventDispatcher\Event is deprecated in drupal:9.1.0 for the cause of these branch failures). Let's try to avoid making the situation worse.

Because this is just a test, we can afford to remove the explicit Event type hint in order to make the code run in both D9 and D10.

Note: This patch contains a test module named 'rules_test_event', which it primarily intended for use in test cases. But you may also enable this test module using drush if you first add the line $settings['extension_discovery_scan_tests'] = TRUE; somewhere in your settings.php. Once you enable this module, you will have access to some test events (in the 'Tests' category) and you may use these test events to trigger any Rules you like. There is also a test page defined at /dispatch-form that allows you to manually dispatch these test events from the browser. This is very useful for manual testing!

#24 fixes the two D10 failures caused by the code in this patch. It does not fix two failures that come from the same problem as in #3259445: Symfony\Component\EventDispatcher\Event is deprecated in drupal:9.1.0 - those can't be avoided in this patch.

In summary, I think #24 is ready to commit (the two coding standards warnings will be fixed on commit, to keep from cluttering this issue with yet another patch).

Committed #24. This patch adds new capability without changing the existing capability, so I don't have any BC concerns. There are plenty of new tests added to ensure the new capability works properly.