Yep, that's exactly right, Ryan. :-) (We'll make a Drupal dev out of
you yet...)
I agree that many "tell me about yourself" operations belong in the DIC,
now that we have that, but not all can go there. For instance, many
routes will be based off of user configuration, by design, and those
can't be regenerated from the DIC in a cleanly injected fashion (as far
as I'm aware, anyway). (Besides, putting Routes into the DIC seems even
weirder.)
The question was "is there a better or more Symfonic way to do it than a
double event"? It looks like the answer is "eh, not really". So, we'll
stick with that for now until someone comes up with something better. :-)
--Larry Garfield
On 11/8/12 8:15 AM, ryan weaver wrote:
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
<mailto: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 <mailto: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 <http://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
<mailto:symfony-devs@googlegroups.com>
To unsubscribe from this group, send email to
symfony-devs+unsubscribe@__googlegroups.com
<mailto: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
<http://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 <mailto:symfony-devs@googlegroups.com>
To unsubscribe from this group, send email to
symfony-devs+unsubscribe@__googlegroups.com
<mailto: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 <http://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
<mailto:symfony-devs@googlegroups.com>
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
<mailto:symfony-devs%2bunsubscr...@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
--
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
