I liked the idea. I would like to see it in the core code but seems more suitable for a bundle, since there is not a single listener in Symfony2 that needs this wildcard matcher.
On Wed, Aug 17, 2011 at 2:02 PM, Jeremy Mikola <jmik...@gmail.com> wrote: > I have a task on my plate at OpenSky where it would be extremely helpful to > have a way to listen on many events. Beyond the standard Symfony2 events > (e.g. core.request, core.exception), we have plenty of custom events in > place where this feature would really shine. Here's a snippet from our spec: > > The AMQP routing wildcard format (used by ActiveMQ, HornetQ, RabbitMQ, et >> al.) would work well: >> >> * >> http://hornetq.sourceforge.net/docs/hornetq-2.0.0.GA/user-manual/en/html/wildcard-syntax.html >> * http://www.rabbitmq.com/faq.html#wildcards-in-topic-exchanges >> >> The "#" and "*" symbols would be used as multi-word or single-word >> wildcards, respectively, where words are separated by periods. This meshes >> well with Symfony2's existing naming convention for events (dot-separated), >> which we also use for our application's custom events. >> > > Basically... a listening on core.* would catch core.request but not > core.request.foo (if such a thing existed). Listening on core.# would catch > both and really anything starting with "core.". I realize there's no > requirement for events to be named in this dot-separated format, but our app > happens to follow the same conventions as the core framework events. > > I can either implement this as a PR for Symfony2's EventDispatcher, or > perhaps as a bundle that replaces the EventDispatcher service (or redefines > "event_dispatcher.class"). The Form component appears to be the only hard > reference to Symfony2's EventDispatcher class, but I think that's OK because > it uses an internal dispatcher for its own events. > > Also, Johannes mentioned that this would add a non-trivial performance cost > to event dispatching (since we'd have to match some patterns instead of only > doing array index checks). Perhaps that's more reason for it to be a bundle. > > Thoughts? Would anyone else even benefit from this kind of feature? > > -- > 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 symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
