-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
[Workflow] Example on reacting to successful transitions #7416
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -175,12 +175,65 @@ what actions are allowed on a blog post:: | |
$transitions = $workflow->getEnabledTransitions($post); | ||
|
||
Using Events | ||
------------ | ||
============ | ||
|
||
To make your workflows even more powerful you could construct the ``Workflow`` | ||
object with an ``EventDispatcher``. You can now create event listeners to | ||
block transitions (i.e. depending on the data in the blog post). The following | ||
events are dispatched: | ||
object with an ``EventDispatcher``. If you are using the ``Workflow`` component within | ||
the Symfony standard edition, this is already done for you. | ||
|
||
When a workflow subject's state is updated, the component dispatches several events that | ||
enable you to alter the component's behaviour: | ||
|
||
* ``workflow.[workflow name].guard.[transition name]``: used to conditionally block a transition. | ||
* ``workflow.[workflow name].leave.[state name]``: a subject leaves a state. | ||
* ``workflow.[workflow name].transition.[transition name]``: a transition is being applied. | ||
* ``workflow.[workflow name].enter.[state name]``: a subject enters a state. | ||
* ``workflow.[workflow name].announce.[transition name]``: a transition was applied to the subject. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps this deserves a note that a |
||
|
||
Reacting to a successful transition | ||
----------------------------------- | ||
|
||
You can create an event listener that would perform some actions when a transition has been applied. | ||
To do so, the event listener needs to have a method accepting the | ||
:class:`Symfony\\Component\\Workflow\\Event\\Event` being dispatched, and a tag in the service | ||
container. | ||
|
||
The following example resembles a mailer that notifies an administrator of posts that have been sent | ||
to review:: | ||
|
||
use Symfony\Component\Workflow\Event\Event; | ||
use Symfony\Component\EventDispatcher\EventSubscriberInterface; | ||
|
||
class BlogPostProposedListener implements EventSubscriberInterface | ||
{ | ||
// Passing the mailer to the listener is omitted for brevity | ||
private $mailer; | ||
|
||
public function notifyPostProposal(Event $event) | ||
{ | ||
/** @var \AppBundle\Entity\BlogPost $post */ | ||
$post = $event->getSubject(); | ||
|
||
$message = \Swift_Message::newInstance('New blog post proposed'); | ||
$message->setTo(['admin@acme.co' => 'Admin']); | ||
$message->setBody('A post has been submitted to review: '.$post->getTitle()); | ||
|
||
$this->mailer->send($message); | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You forgot to really send the mail. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed :) |
||
|
||
public static function getSubscribedEvents() | ||
{ | ||
return array( | ||
'workflow.blogpost.announce.to_review' => array('notifyPostProposal'), | ||
); | ||
} | ||
} | ||
|
||
Blocking transitions | ||
-------------------- | ||
|
||
You can create Guard event listeners to block transitions (i.e. depending on the data in the blog | ||
post). The following events are dispatched: | ||
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The events have already been listed in the previous section here. We could remove the list here, and add a note on |
||
|
||
* ``workflow.guard`` | ||
* ``workflow.[workflow name].guard`` | ||
|
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should reword these descriptions a bit. The essential thing to document about events is if they are notified before or after something happened (that's why it's recommended to name the events
post_*
andpre_*
). For example,a transition is being applied
could be:notified just before applying a transition