Event Constants & @Event Docs

just as you want :D
https://symfony.com/blog/ne...

Hey Yaroslav Y.

That's a great observation, and the reason is that this was not done regionally in Symfony because the ClassName::class keyword didn’t exist back then, but these days, yes, we should start making the event name just the class name. Probably someday Symfony will change it.

Cheers!

Hello, I had the same issue and that was in my FilterApiResponseEvent I was extending Symfony\Contracts\EventDispatcher\Event instead of

Symfony\Component\EventDispatcher\Event;

I also clear my var/cache in my Bundle
I write it for future users

Hey triemli!

Excellent question! Normally (in your application) all you need to do is create a class that implements EventSubscriberInterface and... boom! Symfony magically sees it and registers it with the event dispatcher. That is thanks to "autoconfigure: true", which we don't normally use in bundles (since we prefer to configure everything explicitly.

So, if you're registering an event subscriber in your bundle, you'll need to give it a tag: kernel.event_subscriber - something like:

<service id="whatever_your_service_id_is" class="Acme\Whatever\Your\EventSubscriber\ClassNameIs">
    <!-- whatever arguments here -->
    <tag name="kernel.event_subscriber" />
</service>

Cheers!

Hah after register in service.xml it works. But on you we didn't register, isn't?

Hey triemli

You're right. Ryan didn't configure the event subscriber inside the bundle and it works because the main application has autoconfiguration enabled.
Cheers!

Hm. THat's weird, because I had autoconfiguration is true too

Interesting... what Symfony version are you using? Maybe that "recently" changed

I just download Course code and made composer install.

Hmm, so you're on Symfony4.0

I'm not sure now but it's recommended to configure your bundle's services explicitly, assuming that the main application won't have autoconfigure enabled

Hey julien_bonnier!

Full disclosure I might be a little OCD and I HATE deprecation warnings. So... I tried to make the bundle as backward compatible as possible using Symfony 4.4.

Ha! No problem. Actually, you should probably be a little OCD about deprecations in a bundle: if your bundles triggers deprecations, you will hear about it from your users ;).

About the events, there may be a more clever solution than this, but here is what comes to mind:

use Symfony\Contracts\EventDispatcher\Event as ContractEvent;
use Symfony\Component\EventDispatcher\Event as ComponentEvent;


if (class_exists(ContractEvent::class)) {
    class FilterApiResponseEvent extends ContractEvent
    {
        // the inside of the class
    }
} else {
    class FilterApiResponseEvent extends ComponentEvent
    {
        // the same inside of the class
    }
}

That should do it. You will have to duplicate the inside of the event, but hopefully that's not too much (there may also be a clever way around that that I'm not thinking about). Supporting multiple versions of Symfony like this is super hard - it's tricky for me, even though I have a fair amount of experience. And it often requires you to write weird code that would never otherwise be "ok" ;). This is also why it's important to have your test suite run against your normal dependencies but also against your "low" dependencies (e.g. https://github.com/SymfonyCasts/reset-password-bundle/blob/96391ea830a24bc2dcfc4437edd6648cc55ebcfd/.github/workflows/ci.yml#L184 ).

Let me know if it helps!

Cheers!

I see, I didn't think of it, and I don't like to duplicate code, but I understand that sometimes, when you want your code to support different versions of a framework you have to do some acrobatics. Any way thanks for the answer.

Cheers

Haha, indeed! When it comes to writing reusable code... and supporting different versions of Symfony or PHP... things can get INSANE. The rules are quite different :). And that's kind of the goal of many open source authors: they do a lot of the weird & hard work, so that application developers have an easy life. Welcome to the dark side ;)

Cheers!