Fixed an error in EventDispatcher::disconnect
The behaviour of disconnect() didn't match its description: If you pass NULL as the listener, no listener instead of all an event's listeners is disconnected. I added the missing check for null and a test for it.Added support (like already described in DocCode) for listeners, which are notified on all events. They have to be connected to the event with the name NULL.
I added some first tests. Probably some more tests to verify notify/filter/notifyAll/... should be added as well to guarantee correct behavior if those methods stop using getListeners().
- Source
- Commits
- Network
- Pull Requests (3)
- Graphs
-
Branch:
master
bzikarsky wants someone to pull 3 commits into symfony:master from bzikarsky:master
Showing 1 comment with 3 commits and 1 commit comment
Comment on this pull request
You must be logged in to comment on pull requests.
Showing 3 unique commits by 1 author.
1af0e369
|
![]() |
|
|
|
da8ed51a
|
![]() |
|
|
|
5cd5655c
|
![]() |
|
![]() |
|
Showing 2 changed files with 58 additions and 16 deletions.
src/Symfony/Component/EventDispatcher/EventDispatcher.php | 54 | |
tests/Symfony/Tests/Component/EventDispatcher/EventDispatcherTest.php | 20 |
... | ... |
|
24 | 24 |
|
25 | 25 |
|
26 | 26 |
|
27 |
|
|
28 |
|
|
29 |
|
|
27 |
|
|
28 |
|
|
29 |
|
|
30 | 30 |
|
31 | 31 |
|
32 | 32 |
|
... | ... |
|
40 | 40 |
|
41 | 41 |
|
42 | 42 |
|
43 |
|
|
44 |
|
|
43 |
|
|
44 |
|
|
45 | 45 |
|
46 | 46 |
|
47 | 47 |
|
48 |
|
|
48 |
|
|
49 | 49 |
|
50 | 50 |
|
51 | 51 |
|
52 | 52 |
|
53 | 53 |
|
54 |
|
|
55 |
|
|
56 |
|
|
57 |
|
|
58 |
|
|
54 | 59 |
|
55 | 60 |
|
56 | 61 |
|
... | ... |
|
69 | 74 |
|
70 | 75 |
|
71 | 76 |
|
72 |
|
|
77 |
|
|
73 | 78 |
|
74 | 79 |
|
75 | 80 |
|
... | ... |
|
85 | 90 |
|
86 | 91 |
|
87 | 92 |
|
88 |
|
|
93 |
|
|
89 | 94 |
|
90 | 95 |
|
91 | 96 |
|
... | ... |
|
105 | 110 |
|
106 | 111 |
|
107 | 112 |
|
108 |
|
|
113 |
|
|
109 | 114 |
|
110 | 115 |
|
111 | 116 |
|
... | ... |
|
117 | 122 |
|
118 | 123 |
|
119 | 124 |
|
120 |
|
|
125 |
|
|
126 |
|
|
127 |
|
|
121 | 128 |
|
122 | 129 |
|
123 | 130 |
|
124 |
|
|
131 |
|
|
125 | 132 |
|
126 |
|
|
133 |
|
|
127 | 134 |
|
128 | 135 |
|
129 | 136 |
|
130 | 137 |
|
131 | 138 |
|
132 |
|
|
133 |
|
|
139 |
|
|
140 |
|
|
141 |
|
|
134 | 142 |
|
135 | 143 |
|
136 |
|
|
144 |
|
|
137 | 145 |
|
138 | 146 |
|
139 | 147 |
|
140 | 148 |
|
141 |
|
|
149 |
|
|
142 | 150 |
|
143 | 151 |
|
152 |
|
|
153 |
|
|
154 |
|
|
155 |
|
|
156 |
|
|
157 |
|
|
158 |
|
|
159 |
|
|
160 |
|
|
161 |
|
|
162 |
|
|
163 |
|
|
164 |
|
|
165 |
|
|
144 | 166 |
|
145 | 167 |
|
146 | 168 |
|
... | ... |
|
30 | 30 |
|
31 | 31 |
|
32 | 32 |
|
33 |
|
|
34 |
|
|
35 |
|
|
36 |
|
|
33 | 37 |
|
34 | 38 |
|
35 | 39 |
|
... | ... |
|
100 | 104 |
|
101 | 105 |
|
102 | 106 |
|
107 |
|
|
108 |
|
|
109 |
|
|
110 |
|
|
111 |
|
|
112 |
|
|
113 |
|
|
114 |
|
|
115 |
|
|
116 |
|
|
117 |
|
|
118 |
|
|
119 |
|
|
120 |
|
|
121 |
|
|
122 |
|
|
103 | 123 |
|
104 | 124 |
|
105 | 125 |
|
Tue Oct 12 17:56:04 -0700 2010
1af0e36
da8ed51
5cd5655
5cd5655
Tue Oct 12 22:37:43 -0700 2010
I don't see a need for global event listeners; and I don't see how you can write one. The behavior of a listener depends on the type (notify, filter, ...). The arguments are different for all events. So, except if you have a useful usage and a concrete example of such a need for that, I won't add this feature.
Wed Oct 13 02:10:04 -0700 2010
Maybe I was too unclear about "global" in this case, What I refer to is a listener which fires on all events on a dispatcher. I was quite sure, I read in somewhere in the doc code, but can't find it right now. Anyway what I would use it for:
Dynamic events: I have a case, where a generic event_listener is injected by a "third" class, which does not know yet which events the event_listener will listen to. This is solvable by implementing a method
setupEventListeners(EventDispatcher $ed)
on the object, instead of callingBut there are downsides if there are lots of event-listeners and you don't know whether they have been added yet. So you got to check the existence each time. It'd be much easier when just can throw in an event listener, listening to all events.
Maybe I can write an even fine-grained control by interpreting "" as wildcard in a name. Then "" would be global, but you could also add listeners to specific categories of events, like "client.*".