Skip to content

Commit 74cda20

Browse files
committed
minor #8059 [Workflow] rearrange how workflow events are presented (xabbuh)
This PR was merged into the 3.2 branch. Discussion ---------- [Workflow] rearrange how workflow events are presented see @weaverryan's suggestion in #8048 (comment) Commits ------- f7405d2 rearrange how workflow events are presented
2 parents 1cd1950 + f7405d2 commit 74cda20

File tree

1 file changed

+50
-31
lines changed

1 file changed

+50
-31
lines changed

workflow/usage.rst

Lines changed: 50 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -148,7 +148,7 @@ like this:
148148
The marking store type could be "multiple_state" or "single_state".
149149
A single state marking store does not support a model being on multiple places
150150
at the same time.
151-
151+
152152
.. tip::
153153

154154
The ``type`` (default value ``single_state``) and ``arguments`` (default value ``marking``)
@@ -189,49 +189,68 @@ Each step has three events that are fired in order:
189189
* An event for the workflow concerned;
190190
* An event for the workflow concerned with the specific transition or place name.
191191

192-
The following events are dispatched:
192+
When a state transition is initiated, the events are dispatched in the following
193+
order:
193194

194-
* ``workflow.guard``
195-
* ``workflow.[workflow name].guard``
196-
* ``workflow.[workflow name].guard.[transition name]``
195+
``workflow.guard``
196+
Validate whether the transition is allowed at all (:ref:`see below <workflow-usage-guard-events>`).
197+
198+
The three events being dispatched are:
199+
200+
* ``workflow.guard``
201+
* ``workflow.[workflow name].guard``
202+
* ``workflow.[workflow name].guard.[transition name]``
203+
204+
``workflow.leave``
205+
The object is about to leave a place.
206+
207+
The three events being dispatched are:
197208

198-
* ``workflow.leave``
199-
* ``workflow.[workflow name].leave``
200-
* ``workflow.[workflow name].leave.[place name]``
209+
* ``workflow.leave``
210+
* ``workflow.[workflow name].leave``
211+
* ``workflow.[workflow name].leave.[place name]``
201212

202-
* ``workflow.transition``
203-
* ``workflow.[workflow name].transition``
204-
* ``workflow.[workflow name].transition.[transition name]``
213+
``workflow.transition``
214+
The object is going through this transition.
205215

206-
* ``workflow.enter``
207-
* ``workflow.[workflow name].enter``
208-
* ``workflow.[workflow name].enter.[place name]``
216+
The three events being dispatched are:
209217

210-
* ``workflow.announce``
211-
* ``workflow.[workflow name].announce``
212-
* ``workflow.[workflow name].announce.[transition name]``
218+
* ``workflow.transition``
219+
* ``workflow.[workflow name].transition``
220+
* ``workflow.[workflow name].transition.[transition name]``
213221

214-
When a state transition is initiated, the events are fired in the following order:
222+
``workflow.enter``
223+
The object entered a new place. This is the first event where the object
224+
is marked as being in the new place.
215225

216-
- guard: Validate whether the transition is allowed at all (:ref:`see below <workflow-usage-guard-events>`);
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.
226+
The three events being dispatched are:
227+
228+
* ``workflow.enter``
229+
* ``workflow.[workflow name].enter``
230+
* ``workflow.[workflow name].enter.[place name]``
231+
232+
``workflow.announce``
233+
Triggered once for each workflow that now is available for the object.
234+
235+
The three events being dispatched are:
236+
237+
* ``workflow.announce``
238+
* ``workflow.[workflow name].announce``
239+
* ``workflow.[workflow name].announce.[transition name]``
221240

222241
Here is an example how to enable logging for every time a the "blog_publishing" workflow leaves a place::
223242

224243
use Psr\Log\LoggerInterface;
225244
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
226245
use Symfony\Component\Workflow\Event\Event;
227-
246+
228247
class WorkflowLogger implements EventSubscriberInterface
229248
{
230249
public function __construct(LoggerInterface $logger)
231250
{
232251
$this->logger = $logger;
233252
}
234-
253+
235254
public function onLeave(Event $event)
236255
{
237256
$this->logger->alert(sprintf(
@@ -242,7 +261,7 @@ Here is an example how to enable logging for every time a the "blog_publishing"
242261
implode(', ', $event->getTransition()->getTos())
243262
));
244263
}
245-
264+
246265
public static function getSubscribedEvents()
247266
{
248267
return array(
@@ -253,14 +272,14 @@ Here is an example how to enable logging for every time a the "blog_publishing"
253272

254273
.. _workflow-usage-guard-events:
255274

256-
Guard events
275+
Guard Events
257276
~~~~~~~~~~~~
258277

259-
There are a special kind of events called "Guard events". Their event listeners
260-
are invoked every time a call to ``Workflow::can``, ``Workflow::apply`` or
278+
There are a special kind of events called "Guard events". Their event listeners
279+
are invoked every time a call to ``Workflow::can``, ``Workflow::apply`` or
261280
``Workflow::getEnabledTransitions`` is executed. With the guard events you may
262-
add custom logic to decide what transitions that are valid or not. Here is a list
263-
of the guard event names.
281+
add custom logic to decide what transitions that are valid or not. Here is a list
282+
of the guard event names.
264283

265284
* ``workflow.guard``
266285
* ``workflow.[workflow name].guard``

0 commit comments

Comments
 (0)