@@ -177,10 +177,23 @@ what actions are allowed on a blog post::
177
177
Using Events
178
178
------------
179
179
180
- To make your workflows even more powerful you could construct the ``Workflow ``
180
+ To make your workflows more flexible, you can construct the ``Workflow ``
181
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:
182
+ block transitions (i.e. depending on the data in the blog post) and do
183
+ additional actions when a workflow operation happened (i.e. sending
184
+ announcements).
185
+
186
+ Each step has three events that are fired in order:
187
+
188
+ - An event for every workflow;
189
+ - An event for the workflow concerned;
190
+ - An event for the workflow concerned with the specific transition or place name;
191
+
192
+ The following events are dispatched:
193
+
194
+ * ``workflow.guard ``
195
+ * ``workflow.[workflow name].guard ``
196
+ * ``workflow.[workflow name].guard.[transition name] ``
184
197
185
198
* ``workflow.leave ``
186
199
* ``workflow.[workflow name].leave ``
@@ -198,6 +211,14 @@ events are dispatched:
198
211
* ``workflow.[workflow name].announce ``
199
212
* ``workflow.[workflow name].announce.[transition name] ``
200
213
214
+ When a state transition is initiated, the events are fired in the following order:
215
+
216
+ - guard: Validate whether the transition is allowed at all (see below);
217
+ - leave: The object is about to leave a place;
218
+ - transition: The object is going through this transition;
219
+ - enter: The object entered a new place. This is the first event where the object' is marked as being in the new place;
220
+ - announce: Triggered once for each workflow that now is available for the object.
221
+
201
222
Here is an example how to enable logging for every time a the "blog_publishing" workflow leaves a place::
202
223
203
224
use Psr\Log\LoggerInterface;
0 commit comments