public static function getSubscribedEvents() {
  $events[KernelEvents::REQUEST][] = (new DrupalEventSubscriber($this, 'someMethod'))
    ->before('some.other.event.subscription.service:method')
    ->after('yet.another.event.subscription.service:method');
  return $events;
}
CommentFileSizeAuthor
#22 2352351-22.patch11.36 KBdawehner
#22 interdiff-2352351.txt4.06 KBdawehner
#20 interdiff-2352351.txt1.11 KBdawehner
#20 2352351-20.patch10.29 KBdawehner
#18 2352351-18.patch10.19 KBdawehner

Comments

chx’s picture

chx commented
Issue summary: View changes
fabianx’s picture

fabianx commented

I really like the API idea here! :)

chx’s picture

chx commented
Related issues: +#1972300: Write a more scalable dispatcher
chx’s picture

chx commented
Issue summary: View changes

dawehner points out that

  1. HtmlViewSubscriber has two methods on the same event
  2. If we only use the service name then a later core release can't add more methods in the same class.

So borrowing the service:method fairly ubiquitous syntax (due to ControllerResolver/ClassResolver).

sdboyer’s picture

sdboyer commented

this is graphsort, and we could def use gliph to facilitate it.

if it's just operating on strings then i'd probably need to write another graph implementation that allows non-objects...and update the php5.3 branch to php5.4. but that's all fine and doable, and i'd be willing to do it to facilitate this.

chx’s picture

chx commented

Yes, it's topological sort again, but since module dependencies do not use glyph but my really primitive little graph class I will use just that. When module dependencies convert to glyph this can too. It's really simple except where some some already have weights.

znerol’s picture

znerol commented

What happens if a referenced service is not available in the container for some reason? Either as a result of an alter-implementation or because it is not always present in the first place?

chx’s picture

chx commented

Since your subscriber prescribed a hard dependency we put a 'broken' flag on it and have the dispatcher throw an exception? We don't want the container rebuild to throw an exception, do we.

Crell’s picture

Crell commented

This very strongly feels like something that belongs upstream in Symfony directly. We still have a little time before 2.7. :-)

chx’s picture

chx commented

Then it won't be who writes it because this is too much work to throw away aka MIT license it. Otherwise, I might look at it in December...

fabianx’s picture

fabianx commented

I think we can add our own implementation first and then upstream can take the idea if they want?

Crell’s picture

Crell commented

And then switch ours? No, start upstream. I've had multiple requests from the Symfony folks to work more closely with them to avoid duplication, as they *would* like some of the improvements we're making. At least start the conversation upstream and see if they're interested. We have a Symfonian now coming to the weekly WSCCI meetings if you want to talk real time first. Stop on by this Thursday. :-)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Version: 8.2.x-dev » 8.3.x-dev
Priority: Normal » Major
Issue tags: +DX (Developer Experience), +DrupalWTF, +blocker
Related issues: +#2566019: [PP-1] HtmlResponseSubscriber and DynamicPageCacheSubscriber should have negative priorities so that vanilla response subscribers can have priority zero

Postponed #2566019: [PP-1] HtmlResponseSubscriber and DynamicPageCacheSubscriber should have negative priorities so that vanilla response subscribers can have priority zero on this. Inheriting its issue tags.

dawehner’s picture

dawehner
Primary language German
commented
Assigned: Unassigned » dawehner

I'm working on it at the moment.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dawehner’s picture

dawehner
Primary language German
commented
Assigned: dawehner » Unassigned
Status: Active » Needs review
StatusFileSize
new 2352351-18.patch10.19 KB

After some experiments I believe with linear interpolation we can actually keep full BC compliance, potentially.

This patch uses the following idea:

  • Based upon manual set prioirities and dependencies setup a graph
  • Order the dependency graph
  • Given the previous priorities calculate priorities for dependency based subscribers using linear interpolation
  • Hopefully profit.

Status: Needs review » Needs work

The last submitted patch, 18: 2352351-18.patch, failed testing.

dawehner’s picture

dawehner
Primary language German
commented
Status: Needs work » Needs review
StatusFileSize
new 2352351-20.patch10.29 KB
new interdiff-2352351.txt1.11 KB

This could fix a good couple of failures.

Status: Needs review » Needs work

The last submitted patch, 20: 2352351-20.patch, failed testing.

dawehner’s picture

dawehner
Primary language German
commented
Status: Needs work » Needs review
StatusFileSize
new interdiff-2352351.txt4.06 KB
new 2352351-22.patch11.36 KB

This could be quite some less failures ...

Status: Needs review » Needs work

The last submitted patch, 22: 2352351-22.patch, failed testing.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joachim’s picture

joachim commented

I like this idea, but we need to be aware that it introduces a major change in what counts as internal and what counts as public when it comes to events.

Currently, an ES must implement getSubscribedEvents(), for example:

  public static function getSubscribedEvents() {
    // Subscribe to kernel terminate with priority 100.
    $events[KernelEvents::TERMINATE][] = array('onTerminate', 100);
    // Subscribe to kernel request with default priority of 0.
    $events[KernelEvents::REQUEST][] = array('onRequest');
    return $events;
  }

The methods onTerminate(), onRequest() are public PHP methods, and their signatures are defined by the event system, but I am free to call them what I want and rename them whenever I like at any time without affecting anything. The thing I mustn't change is the priority values, as that could break other another module that is expecting my listener to run, say, at priority 100, and has set its own listener to run at a higher or lower value. (Though I don't believe that is actually documented properly anywhere.)

With the new system, another module that wants to ensure it runs relative to my listener will no longer care about a priority value, but it will explicitly reference my method names.

So the names of methods in the event subscriber class have effectively become part of my module's public API, and may NOT be changed as that would break other modules.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Issue tags: +Needs reroll
Related issues: +#2352351: Add before/after ordering to events

Re

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Related issues: -#2352351: Add before/after ordering to events

whoops

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

This would be so much better 🙏

sokru’s picture

sokru commented
Issue tags: -Needs reroll

Doesn't need a reroll, since patch from #22 applies cleanly.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

amateescu’s picture

amateescu commented

One idea for the issue mentioned in #25 could be that the before/after syntax will specify "providers" (module names), because that's the majority use-case for this feature: "I want my hook/event implementation to run before or after the same hook/event from module X".

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.