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
Comment #2
Crell CreditAttribution: Crell at Platform.sh commentedComment #3
dawehnerOne 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.
Comment #4
Crell CreditAttribution: Crell at Platform.sh commentedYep, 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.)
Comment #5
xjmComment #6
Crell CreditAttribution: Crell at Platform.sh commentedComment #7
dawehnerhttps://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
.Comment #8
Crell CreditAttribution: Crell at Platform.sh commentedSee the OP: Ignore the current state of the proposal. It's going to change. No one thinks what's there now is reasonable. :-)
Comment #9
dawehnerAh cool, so yeah I think we should encorage domain logic and not support basically a glorified hashmap.
Comment #10
Crell CreditAttribution: Crell at Platform.sh commentedI'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.)
Comment #11
tim.plunkettI 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?
Comment #12
Crell CreditAttribution: Crell at Platform.sh commentedWell, 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.
Comment #13
dawehnerThat'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:
?? 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:
Event dispatcher
...
Comment #14
dawehner@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.
Comment #15
Crell CreditAttribution: Crell at Platform.sh commentedThe 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. :-)
Comment #16
dawehner@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.Comment #17
dawehner@crell
Thank you for these kind of information.
Comment #18
manchuck CreditAttribution: manchuck commented@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
Comment #19
dawehner@manchuck
Thank you for your follow up! I'm certainly interested in it.
Personally this would make sense for me. One major question is probably whether those event data/objects should have a specific interface or not.
Comment #20
alexpottI 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.
Comment #21
xjm@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.
Comment #22
mkalkbrennerI 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:Comment #23
andypostIn terms of 9.1+ and PHP 8 changes to reason to postpone at least discussion
Comment #24
catchMarking duplicate of #3055194: [Symfony 5] The signature of the "Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch()" method should be updated to "dispatch($event, string $eventName = null)", not doing so is deprecated since Symfony 4.3..