Hi guys! Larry, correct me if I'm wrong, but basically here is the situation (I tried catching up on the Drupal thread, but I was starting a bit behind :) )
To load dynamic routes in Drupal, we need to throw an event. In that event, different modules (i.e. listeners) will basically return the routes they need registered. This is the "info" hook (but that name isn't really important for us understanding the flow). THEN, another event would be thrown. This time, the full aggregate RouteCollection that was built by all the listeners in the first event is passed around to these listeners. The purpose is that listeners can now mutate that RouteCollection. This is the "alter" hook. Two events are thrown so that anyone who needs to alter routes is guaranteed to have all of them loaded already by the time they are notified as a listener. I *think* (and Larry - yell if I'm wrong - at least I'll have clarified in my misunderstanding!) the question comes to this: is there a spot in the Symfony world where we have a pattern that is similar to this (i.e. where we throw 2 events in a row - 1 to collect all the information and another to allow that information to be mutated)? I personally don't know of one - the only analogous area is the (a) building of the container and then (b) compiler passes. So for me, the 2 events seem very non-traditional, but I also can't think of another way to do this. Cheers! Ryan Weaver US Office Head & Trainer - KnpLabs - Nashville, TN http://www.knplabs.com <http://www.knplabs.com/en> http://knpuniversity.com Twitter: @weaverryan On Wed, Nov 7, 2012 at 6:37 PM, Thomas Rabaix <tho...@rabaix.net> wrote: > Larry, > > Can you explain the use cases for such hooks? Most of computation should > be done while the DIC is being built so on a standard request no important > computation is done. > > So if my understanding is good, the DIC should contains all configurations > and hooks must be replaced by an Events to only alter the targeted data > (ie, the node, the form ...) based on services definitions. > > The "tell me about yourself" must be done when the container is built by > using mechanism from the Dependency Injection Component. Now, I don't know > the current implementation in Drupal, but in Symfony2 (the full stack > framework), there is no "information" metadata where a bundle can register > or provide information about what features a bundle implements. > > > > > > On Wed, Nov 7, 2012 at 5:20 PM, Larry Garfield <la...@garfieldtech.com>wrote: > >> Hi Bernhard. >> >> I'm not sure I follow. With both GetResponseEvent and PostResponseEvent, >> I can retrieve the request/response objects. Because of the way objects >> pass in PHP, both are mutable in practice. >> >> When I say "info" hooks/events, I don't mean notification events. I mean >> "tell me about yourself" data-collection events. For the specific case at >> hand, it would be asking all modules to return a RouteCollection (or in >> other cases an array of objects, or array of arrays), and then deliberately >> allowing other modules to modify that RouteCollection rather than passing >> an event that implicitly allows the collection to be modified by virtue of >> PHP's object passing semantics. >> >> It's certainly possible that I'm over thinking this, but I know I'm going >> to be asked to establish an easy pattern (because Drupal is like that), so >> I want to make sure it's a Symfony-friendly pattern. >> >> --Larry Garfield >> >> >> On 11/7/12 5:16 AM, Bernhard Schussek wrote: >> >>> Hi Larry, >>> >>> Currently, Symfony distinguishes between these sorts of events as you >>> said, by providing mutable or immutable event objects. If an event >>> object is immutable, the event is clearly an "info" event. If the event >>> object is mutable, it would be an "alter" event. >>> >>> For example, GetResponseEvent [1] in HttpKernel is an "alter" event, >>> while PostResponseEvent [2] is an "info" event. >>> >>> I don't think you need a more sophisticated pattern than that. >>> >>> Cheers, >>> Bernhard >>> >>> [1] >>> https://github.com/symfony/**symfony/blob/master/src/** >>> Symfony/Component/HttpKernel/**Event/GetResponseEvent.php<https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Event/GetResponseEvent.php> >>> [2] >>> https://github.com/symfony/**symfony/blob/master/src/** >>> Symfony/Component/HttpKernel/**Event/PostResponseEvent.php<https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Event/PostResponseEvent.php> >>> >>> -- >>> 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+unsubscribe@**googlegroups.com<symfony-devs%2bunsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/**group/symfony-devs?hl=en<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+unsubscribe@**googlegroups.com<symfony-devs%2bunsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/**group/symfony-devs?hl=en<http://groups.google.com/group/symfony-devs?hl=en> >> > > > > -- > Thomas Rabaix > http://rabaix.net | http://sonata-project.org > > -- > 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
