On Mon, Nov 15, 2010 at 1:12 PM, Fabien Potencier < [email protected]> wrote:
> On 11/15/10 6:54 PM, Jeremy Mikola wrote: > >> I think it's worthwhile being able to disconnect a specific listener. >> In Symfony1, various plugins had listeners that injected assets into the >> response (e.g. an outdated jQuery version), which I wanted to disable. >> > > This example is not a good one as using a listener to inject resources is > probably a bad idea. I think that disabling the registration is probably > the best thing to do instead of disconnecting a listener. What do you think? I completely agree that it shouldn't be necessary if plugins were all well-designed, but it is a practical problem I've faced. I'm hesitant to say that everyone should make listener registrations optional (even with an opt-in default value), as that's a bit of overhead code to allow things to be disabled. And what would that entail exactly, removing the "kernel.listener" tag when processing the config? As Lukas mentioned, we shouldn't have too much trouble patching things upstream with DVCS, so I'm ok handling these on a case-by-case basis as I encounter bundles with limitations. Was the single-listener mode for disconnect() a candidate for removal? I'm not sure why it was brought up in the OP (I will say I like the idea of using SplPriorityQueue, though). -- jeremy mikola -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
