Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Commit c0a172a

Browse filesBrowse files
weaverryanweaverryan
committed
Merge branch '3.2' into 3.3
* 3.2: Use Twig's namespaced paths Minor reword Clearify setup of basic auth for test environment rearrange how workflow events are presented
2 parents 57a7a12 + 13adec3 commit c0a172a
Copy full SHA for c0a172a

File tree

3 files changed

+66
-37
lines changed
Filter options

3 files changed

+66
-37
lines changed

‎profiler/data_collector.rst

Copy file name to clipboardExpand all lines: profiler/data_collector.rst
+1-1Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -117,7 +117,7 @@ block and set the value of two variables called ``icon`` and ``text``:
117117

118118
.. code-block:: html+twig
119119

120-
{% extends 'WebProfilerBundle:Profiler:layout.html.twig' %}
120+
{% extends '@WebProfiler/Profiler/layout.html.twig' %}
121121

122122
{% block toolbar %}
123123
{% set icon %}

‎testing/http_authentication.rst

Copy file name to clipboardExpand all lines: testing/http_authentication.rst
+6-3Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -30,14 +30,16 @@ firewall, but only in the configuration file used by tests:
3030
# app/config/config_test.yml
3131
security:
3232
firewalls:
33-
your_firewall_name:
33+
# replace 'main' by the name of your own firewall
34+
main:
3435
http_basic: ~
3536
3637
.. code-block:: xml
3738
3839
<!-- app/config/config_test.xml -->
3940
<security:config>
40-
<security:firewall name="your_firewall_name">
41+
<!-- replace 'main' by the name of your own firewall -->
42+
<security:firewall name="main">
4143
<security:http-basic />
4244
</security:firewall>
4345
</security:config>
@@ -47,7 +49,8 @@ firewall, but only in the configuration file used by tests:
4749
// app/config/config_test.php
4850
$container->loadFromExtension('security', array(
4951
'firewalls' => array(
50-
'your_firewall_name' => array(
52+
// replace 'main' by the name of your own firewall
53+
'main' => array(
5154
'http_basic' => array(),
5255
),
5356
),

‎workflow/usage.rst

Copy file name to clipboardExpand all lines: workflow/usage.rst
+59-33Lines changed: 59 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -189,53 +189,79 @@ 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:
208+
209+
* ``workflow.leave``
210+
* ``workflow.[workflow name].leave``
211+
* ``workflow.[workflow name].leave.[place name]``
212+
213+
``workflow.transition``
214+
The object is going through this transition.
197215

198-
* ``workflow.leave``
199-
* ``workflow.[workflow name].leave``
200-
* ``workflow.[workflow name].leave.[place name]``
216+
The three events being dispatched are:
201217

202-
* ``workflow.transition``
203-
* ``workflow.[workflow name].transition``
204-
* ``workflow.[workflow name].transition.[transition name]``
218+
* ``workflow.transition``
219+
* ``workflow.[workflow name].transition``
220+
* ``workflow.[workflow name].transition.[transition name]``
205221

206-
* ``workflow.enter``
207-
* ``workflow.[workflow name].enter``
208-
* ``workflow.[workflow name].enter.[place name]``
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.
209225

210-
* ``workflow.entered``
211-
* ``workflow.[workflow name].entered``
212-
* ``workflow.[workflow name].entered.[place name]``
226+
The three events being dispatched are:
213227

214-
* ``workflow.announce``
215-
* ``workflow.[workflow name].announce``
216-
* ``workflow.[workflow name].announce.[transition name]``
228+
* ``workflow.enter``
229+
* ``workflow.[workflow name].enter``
230+
* ``workflow.[workflow name].enter.[place name]``
217231

218-
When a state transition is initiated, the events are fired in the following order:
232+
``work.flow.entered``
219233

220-
- guard: Validate whether the transition is allowed at all (:ref:`see below <workflow-usage-guard-events>`);
221-
- leave: The object is about to leave a place;
222-
- transition: The object is going through this transition;
223-
- enter: The object entered a new place. This is the first event where the object' is marked as being in the new place;
224-
- announce: Triggered once for each workflow that now is available for the object.
234+
Similar to ``workflow.enter``, except the marking store is updated before this
235+
event (making it a good place to flush data in Doctrine).
236+
237+
The three events being dispatched are:
238+
239+
* ``workflow.entered``
240+
* ``workflow.[workflow name].entered``
241+
* ``workflow.[workflow name].entered.[place name]``
242+
243+
``workflow.announce``
244+
Triggered once for each workflow that now is available for the object.
245+
246+
The three events being dispatched are:
247+
248+
* ``workflow.announce``
249+
* ``workflow.[workflow name].announce``
250+
* ``workflow.[workflow name].announce.[transition name]``
225251

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

228254
use Psr\Log\LoggerInterface;
229255
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
230256
use Symfony\Component\Workflow\Event\Event;
231-
257+
232258
class WorkflowLogger implements EventSubscriberInterface
233259
{
234260
public function __construct(LoggerInterface $logger)
235261
{
236262
$this->logger = $logger;
237263
}
238-
264+
239265
public function onLeave(Event $event)
240266
{
241267
$this->logger->alert(sprintf(
@@ -246,7 +272,7 @@ Here is an example how to enable logging for every time a the "blog_publishing"
246272
implode(', ', $event->getTransition()->getTos())
247273
));
248274
}
249-
275+
250276
public static function getSubscribedEvents()
251277
{
252278
return array(
@@ -257,14 +283,14 @@ Here is an example how to enable logging for every time a the "blog_publishing"
257283

258284
.. _workflow-usage-guard-events:
259285

260-
Guard events
286+
Guard Events
261287
~~~~~~~~~~~~
262288

263-
There are a special kind of events called "Guard events". Their event listeners
264-
are invoked every time a call to ``Workflow::can``, ``Workflow::apply`` or
289+
There are a special kind of events called "Guard events". Their event listeners
290+
are invoked every time a call to ``Workflow::can``, ``Workflow::apply`` or
265291
``Workflow::getEnabledTransitions`` is executed. With the guard events you may
266-
add custom logic to decide what transitions that are valid or not. Here is a list
267-
of the guard event names.
292+
add custom logic to decide what transitions that are valid or not. Here is a list
293+
of the guard event names.
268294

269295
* ``workflow.guard``
270296
* ``workflow.[workflow name].guard``

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.