The PHP-FIG has an open PSR in draft, PSR-14, for an "Event Manager" (what we'd call an Event Dispatcher in Symfony):

https://github.com/php-fig/fig-standards/blob/master/proposed/event-mana...

(Ignore the current state of the proposal, it's going to change dramatically.)

The goal is to create a cross-project lightweight interface for what Drupal currently uses hooks and Symfony Events for, so that 3rd party libraries can fire events for that interface and be easily plugged in to Drupal, or Symfony, or Zend, or Laravel, or whatever. The expectation is that each major system will, likely, still have its own implementation of that interface, much as we do for PSR-3. Details of what that will look like have yet to be ironed out.

Fabien Potencier has indicated that he MAY transition Symfony to it as well, IF such a transition is feasible to do without a hard-break.

Under FIG 3, this will turn into a formal Working Group, with Chuck Reeves as the Editor.

Naturally Drupal has a lot of expertise to offer here, as well as a vested interest in the outcome. Therefore, I would like to propose the following:

1) As Drupal FIG Representative, I join the Working Group and work to ensure that Drupal's experience and needs are included in the outcome.

2) We use this thread as a coordination thread to gather and centralize Drupal feedback, and where I will provide periodic updates or requests for feedback. (On a completely arbitrary schedule as most PSRs are developed on an arbitrary and inconsistent schedule.)

3) Drupal states an intention to at least try to implement PSR-14 in our next major version (Drupal 9). While FIG members are not required to implement any PSR, there is an expectation that we will give them "due consideration". And if we're involved in the creation of the spec then presumably the outcome is something that we will be able to adopt. If it's not, we screwed up somewhere. :-)

I intend to work on the spec regardless, but I'd rather do so with my official Drupal hat on now that FIG is setup to encourage that.

Tagging to ping the right people...

Comments

Crell created an issue. See original summary.

Crell’s picture

Issue summary: View changes
dawehner’s picture

One thing we should try to make possible as it has bitten us a lot in the development of Drupal 8 is the problem that priority just works when you are framework, which controls basically everything, or have users which write all the custom code. In Drupal though priorities just doesn't work. You want to explicitly be able to specify dependencies between event subscribers, basically after and before, see #2352351: Add before/after ordering to events for a little bit more background.

Honestly I'm not sure how this would look like, but it helps to be able to write generic modules not conflicting with others, and well in general, scale up with the amount of subscribers as we might have, once we would have hooks and events at the same time.

Hooks currently have this great feature that their order is pretty much deterministic (module order), unlike event subscribers, which are more or less random. We need some way to bring in some determinism into them.

Crell’s picture

Yep, ordering one of the questions we're going to have to tackle. I have no idea what it will look like yet to do so, but it's one of the topics I want to bring up.

I'm actually pushing to separate the dispatch and registration sides into separate interfaces in the spec, which should help there and allow some projects (eg, us) to, if necessary, adopt only one half or the other. (Although if we can make both work, so much the better.)

xjm’s picture

Issue tags: -Needs committer feedback +Needs framework manager review
Crell’s picture

Issue summary: View changes
dawehner’s picture

https://github.com/php-fig/fig-standards/blob/master/proposed/event-manager.md
To be honest I think this interface is weird. I think it would be much better to let the domain event object have better methods and just don't expose a lot of internal methods like getParam/setParam.

Crell’s picture

See the OP: Ignore the current state of the proposal. It's going to change. No one thinks what's there now is reasonable. :-)

dawehner’s picture

Ah cool, so yeah I think we should encorage domain logic and not support basically a glorified hashmap.

Crell’s picture

I'm not sure I follow. Can you clarify?

Also, I take it you are on-board with my recommendation in the OP? (Still waiting for one of the managerial folks to weigh in.)

tim.plunkett’s picture

I don't see anything architectural to review here.

I read this as "grant @Crell carte blanche to say anything to FIG and possibly opt Drupal into it", but isn't that what already happens?

Crell’s picture

Well, I'm trying to get more interaction than carte blanche going here... Or at the very least a place to pull input from the Drupal site from people not named Crell.

If we can say up front that we want to implement PSR-14 (which we don't do with most PSRs), that IMO puts us in a better position to say "PSR-14 *needs* to do X", which in turn would make it easier for us to implement. It's a virtuous cycle, or at least that's the intent.

dawehner’s picture

If we can say up front that we want to implement PSR-14 (which we don't do with most PSRs), that IMO puts us in a better position to say "PSR-14 *needs* to do X", which in turn would make it easier for us to implement

That's a weird logic. How can we agree on something which is not defined yet. Sure if there is a standard which works for us, go with it, but let's don't follow a standard for the sake of it.

I think a more constructive discussion would be to not discuss about PSRs, but rather discuss only about what would an event system suiteable for Drupal look like and then see whether this event system would also be suiteable for others ... This is something which is not clear yet either!

Here is a start, but I'm not convinced that the issue queue is the best way to discuss about it.

Event registration

We need a way to let subscribers be defined.

No specified order

When you don't provide any priority/order of execution we should be able to adapt the order as in order by module name + class name, or order name and order in the services.yml? This order has to be deterministic by default.

Order specification

When you need to be able to specify the order, you should be able to say: I run before X and after Y (with multiple support). This has the following advantages:

  • Its more explicit what happens. You run after, routing, then you specify that you run after routing and not that you have a priority of 31
  • It makes bigger applications easier. This is less important for pure frameworks, but its important for huge systems with a lot of bundles/modules/plugins, of which CMSs/Forum systems are examples of.

?? Potentially this order definitions would be separate from the actual piece of code which gets executed

Event firing

You should be able to fire an event by specifying the following information:

  • A name of the event ?? (Why not just always encode this information on the event object itself)?
  • An event object which contains the data you want to change/subscriber to. If there is a machine name passed in, could we skip the requirement for an event interface?

Event dispatcher

...

dawehner’s picture

@crell
I tried hard, but I could not figure out where these PSR-14 are supposed to happen. There is nothing in the mailing list nor in github.

Crell’s picture

The FIG 3 Core Committee will take office on Christmas. The WG will form soon after. Discussion will likely be on a dedicated mailing list or on the main list, TBD. (We want to better structure PSR discussion with FIG 3, but details are still in progress.) I'm trying to get a jump on matters in this thread. :-)

dawehner’s picture

@Crell
From a process point of view I think what could be useful is to compare other event subscriber systems out there in other languages. I started personally to read up on some of them, and most of them seem to for example not require a dedicated EventInterface but rather just pass along the data, but of course make it possible, if needed to have one.

dawehner’s picture

@crell
Thank you for these kind of information.

manchuck’s picture

@dawehner The current commit you are seeing is from 3 years ago. Back then the purpose of FIG was to create unifying interfaces for different Frameworks. Because of that the original goal of the EventManager was to create a common interface based on what the frameworks at the time where doing. Now that FIG has grown, the EventManager will be refactored to follow traditional event design (iNotify, Windows Event Loop for example). We might even break up the spec into EventManager and Dispatcher. Those both do very different things.

Before the WG gets going, we want to have at least one framework represented. Once that happens I'll make sure you get notice of the where the thread is so you can follow along to see how it develops

dawehner’s picture

@manchuck
Thank you for your follow up! I'm certainly interested in it.

We might even break up the spec into EventManager and Dispatcher.

Personally this would make sense for me. One major question is probably whether those event data/objects should have a specific interface or not.

alexpott’s picture

I agree with @dawehner's point about priority and dependency resolution. With Drupal given the modular architecture if is perfectly possible to have modules that have incompatible expectations. I'm not quite sure what a framework manager has to do at this point on this issue.

xjm’s picture

Project: Drupal core » Drupal core ideas
Version: 9.x-dev »
Component: base system » Idea
Status: Needs review » Postponed

@alexpott, @catch, and I discussed this issue and agreed it belongs in the ideas queue at this point. However, in order to provide architectural feedback, we'd need an up-to-date and concrete proposal to evaluate.

From the release management perspective, we would not block the release of Drupal 9 or any major on adopting this PSR. It would have to be adopted in a way that met our BC requirements and ideally followed the continuous upgrade path policy.

mkalkbrenner’s picture

I just want to mention that we removed the hard dependency to symfony's event-dispatcher in the solarium library, the PHP client for Apache Solr.
In solarium we now do pure PSR-14 compliant event dispatching.

symfony itself became PSR-14 compliant with 4.3. Unfortunately drupal core didn't adopt to it.

In order to get the latest solarium version 6 to work with the search_api_solr module for Drupal 8 and 9 I included a light wight PSR-14-Bridge in search_api_solr 4.1.0:
https://git.drupalcode.org/project/search_api_solr/-/tree/4.x/src/Solari...

like already mentioned in #2876675: Allow symfony/event-dispatcher 4+ to be installed in Drupal 8 I hope that drupal becomes more inclusive for third party libraries in the future.

As I proposed in the past, it is not too late to do something similar to symfony's LegacyEventDispatcherProxy in drupal Core to ease the life for contrib developers and to meet your requirements:

From the release management perspective, we would not block the release of Drupal 9 or any major on adopting this PSR. It would have to be adopted in a way that met our BC requirements and ideally followed the continuous upgrade path policy.

andypost’s picture

Status: Postponed » Needs review

In terms of 9.1+ and PHP 8 changes to reason to postpone at least discussion