@@ -175,12 +175,65 @@ what actions are allowed on a blog post::
175
175
$transitions = $workflow->getEnabledTransitions($post);
176
176
177
177
Using Events
178
- ------------
178
+ ============
179
179
180
180
To make your workflows even more powerful you could construct the ``Workflow ``
181
- object with an ``EventDispatcher ``. You can now create event listeners to
182
- block transitions (i.e. depending on the data in the blog post). The following
183
- events are dispatched:
181
+ object with an ``EventDispatcher ``. If you are using the ``Workflow `` component within
182
+ the Symfony standard edition, this is already done for you.
183
+
184
+ When a workflow subject's state is updated, the component dispatches several events that
185
+ enable you to alter the component's behaviour:
186
+
187
+ * ``workflow.[workflow name].guard.[transition name] ``: dispatched before applying a transition.
188
+ * ``workflow.[workflow name].leave.[state name] ``: a subject leaves a state.
189
+ * ``workflow.[workflow name].transition.[transition name] ``: a transition is being applied.
190
+ * ``workflow.[workflow name].enter.[state name] ``: a subject enters a state.
191
+ * ``workflow.[workflow name].announce.[transition name] ``: a transition was applied to the subject.
192
+
193
+ Reacting to a successful transition
194
+ -----------------------------------
195
+
196
+ You can create an event listener that would perform some actions when a transition has been applied.
197
+ To do so, the event listener needs to have a method accepting the
198
+ :class: `Symfony\\ Component\\ Workflow\\ Event\\ Event ` being dispatched, and a tag in the service
199
+ container.
200
+
201
+ The following example resembles a mailer that notifies an administrator of posts that have been sent
202
+ to review::
203
+
204
+ use Symfony\Component\Workflow\Event\Event;
205
+ use Symfony\Component\EventDispatcher\EventSubscriberInterface;
206
+
207
+ class BlogPostProposedListener implements EventSubscriberInterface
208
+ {
209
+ // Passing the mailer to the listener is omitted for brevity
210
+ private $mailer;
211
+
212
+ public function notifyPostProposal(Event $event)
213
+ {
214
+ /** @var \AppBundle\Entity\BlogPost $post */
215
+ $post = $event->getSubject();
216
+
217
+ $message = \Swift_Message::newInstance('New blog post proposed');
218
+ $message->setTo(['admin@acme.co' => 'Admin']);
219
+ $message->setBody('A post has been submitted to review: '.$post->getTitle());
220
+
221
+ $this->mailer->send($message);
222
+ }
223
+
224
+ public static function getSubscribedEvents()
225
+ {
226
+ return array(
227
+ 'workflow.blogpost.announce.to_review' => array('notifyPostProposal'),
228
+ );
229
+ }
230
+ }
231
+
232
+ Blocking transitions
233
+ --------------------
234
+
235
+ You can create Guard event listeners to block transitions (i.e. depending on the data in the blog
236
+ post). The following events are dispatched:
184
237
185
238
* ``workflow.guard ``
186
239
* ``workflow.[workflow name].guard ``
0 commit comments