[EventDispatcher] A compiler pass for aliased userland events #33793
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bc74dae to
45278e0
Compare
stof
reviewed
Oct 1, 2019
| @@ -78,6 +78,7 @@ | |||
| "symfony/messenger": "<4.3", | |||
| "symfony/mime": "<4.4", | |||
| "symfony/property-info": "<3.4", | |||
| "symfony/security-bundle": "<4.4", | |||
There was a problem hiding this comment.
do we actually need such conflict rule ?
There was a problem hiding this comment.
If you have a Symfony 4.3 application with an event subscriber registered to, let's say, SwitchUserEvent::class, that application would break if you upgraded FrameworkBundle to 4.4 without upgrading SecurityBundle as well.
|
I've backported the new tests to 4.3: #33795 |
src/Symfony/Component/EventDispatcher/DependencyInjection/EventAliasesPass.php
Outdated
Show resolved
Hide resolved
nicolas-grekas
added a commit
that referenced
this pull request
Oct 2, 2019
This PR was merged into the 4.3 branch. Discussion ---------- [EventDispatcher] Added tests for aliased events | Q | A | ------------- | --- | Branch? | 4.3 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | N/A | License | MIT | Doc PR | N/A While working on #33793 I discovered that I could remove the event alias feature of `RegisterListenersPass` without breaking the component's tests. This PR adds the missing tests. Commits ------- 8e8a6ed [EventDispatcher] Added tests for aliased events.
|
(rebase needed) |
6a93842 to
23f570d
Compare
nicolas-grekas
approved these changes
Oct 2, 2019
yceruto
approved these changes
Oct 2, 2019
nicolas-grekas
approved these changes
Oct 2, 2019
|
can you please update the CHANGELOG of the component? |
23f570d to
34efe40
Compare
✅ |
|
Thank you @derrabus. |
nicolas-grekas
added a commit
that referenced
this pull request
Oct 4, 2019
… events (derrabus)
This PR was merged into the 4.4 branch.
Discussion
----------
[EventDispatcher] A compiler pass for aliased userland events
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | TODO
Since 4.3, the EventDispatcher component allows to register events via the FQCN of the class name instead of a dedicated event name.
Earlier this year I have worked with a team that used the event dispatcher for own custom events. When 4.3 was released, the team decided to use the new mechanism for new events. For the sake of consistency, we also wanted to migrate existing event subscribers to FQCN events.
While FrameworkBundle implements a nice aliasing mechanism for its own events, we couldn't find an obvious way to make use of FQCN event aliases for our own events. The best way we could find is registering a compiler pass that would extend an internal parameter that stores all event aliases. But that made us feel like we're fiddling with an implementation detail of the framework.
This PR aims to provide a standard way for applications and third-party bundles to register their own event aliases.
```php
$container->addCompilerPass(new EventAliasesPass([
MyCustomEvent::class => 'my_custom_event',
]));
```
Furthermore, it adds tests for class aliasing to the component's test suite. Additionally, the newly introduced pass is dogfooded by the SecurityBundle, so FrameworkBundle doesn't need to know about events fired by the security components.
Commits
-------
34efe40 [EventDispatcher] A compiler pass for aliased userland events.
This was referenced Nov 12, 2019
Merged
Merged
OskarStark
added a commit
to symfony/symfony-docs
that referenced
this pull request
Feb 7, 2020
This PR was merged into the 4.4 branch. Discussion ---------- [EventDispatcher] Document event name aliases This PR fixes #12418 by documenting symfony/symfony#33793 Question: On the component's doc page, the `sidebar` block "Registering Event Listeners and Subscribers in the Service Container" has grown a bit larger with my changes. Would it make sense to move that block to a dedicated page now? Commits ------- c87632c [EventDispatcher] Document event name aliases.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since 4.3, the EventDispatcher component allows to register events via the FQCN of the class name instead of a dedicated event name.
Earlier this year I have worked with a team that used the event dispatcher for own custom events. When 4.3 was released, the team decided to use the new mechanism for new events. For the sake of consistency, we also wanted to migrate existing event subscribers to FQCN events.
While FrameworkBundle implements a nice aliasing mechanism for its own events, we couldn't find an obvious way to make use of FQCN event aliases for our own events. The best way we could find is registering a compiler pass that would extend an internal parameter that stores all event aliases. But that made us feel like we're fiddling with an implementation detail of the framework.
This PR aims to provide a standard way for applications and third-party bundles to register their own event aliases.
Furthermore, it adds tests for class aliasing to the component's test suite. Additionally, the newly introduced pass is dogfooded by the SecurityBundle, so FrameworkBundle doesn't need to know about events fired by the security components.