Skip to content

[Workflow] Do to talk about workflow, and explain what support option is for #20112

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Aug 26, 2024
Merged

[Workflow] Do to talk about workflow, and explain what support option is for #20112

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 0 additions & 18 deletions components/workflow.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,23 +55,6 @@ The ``Workflow`` can now help you to decide what *transitions* (actions) are all
on a blog post depending on what *place* (state) it is in. This will keep your domain
logic in one place and not spread all over your application.

When you define multiple workflows you should consider using a ``Registry``,
which is an object that stores and provides access to different workflows.
A registry will also help you to decide if a workflow supports the object you
are trying to use it with::

use Acme\Entity\BlogPost;
use Acme\Entity\Newsletter;
use Symfony\Component\Workflow\Registry;
use Symfony\Component\Workflow\SupportStrategy\InstanceOfSupportStrategy;

$blogPostWorkflow = ...;
$newsletterWorkflow = ...;

$registry = new Registry();
$registry->addWorkflow($blogPostWorkflow, new InstanceOfSupportStrategy(BlogPost::class));
$registry->addWorkflow($newsletterWorkflow, new InstanceOfSupportStrategy(Newsletter::class));

Usage
-----

Expand Down Expand Up @@ -100,7 +83,6 @@ method to initialize the object property::

// ...
$blogPost = new BlogPost();
$workflow = $registry->get($blogPost);

// initiate workflow
$workflow->getMarking($blogPost);
Expand Down
30 changes: 3 additions & 27 deletions workflow/workflow-and-state-machine.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,7 @@ Below is the configuration for the pull request state machine.
marking_store:
type: 'method'
property: 'currentPlace'
# The supports options is useful only if you are using twig functions ('workflow_*')
Copy link
Member

@xabbuh xabbuh Aug 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# The supports options is useful only if you are using twig functions ('workflow_*')
# the "supports" option is useful only if you are using Twig functions ('workflow_*')

Copy link
Member

@javiereguiluz javiereguiluz Aug 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did these changes while merging. Thanks!

supports:
- App\Entity\PullRequest
initial_marking: start
Expand Down Expand Up @@ -132,6 +133,7 @@ Below is the configuration for the pull request state machine.
<framework:property>currentPlace</framework:property>
</framework:marking-store>

<!-- The supports options is useful only if you are using twig functions ('workflow_*') -->
Copy link
Member

@xabbuh xabbuh Aug 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<!-- The supports options is useful only if you are using twig functions ('workflow_*') -->
<!-- The "support" option is useful only if you are using Twig functions ('workflow_*') -->

<framework:support>App\Entity\PullRequest</framework:support>

<framework:initial_marking>start</framework:initial_marking>
Expand Down Expand Up @@ -202,6 +204,7 @@ Below is the configuration for the pull request state machine.

$pullRequest
->type('state_machine')
// The supports options is useful only if you are using twig functions ('workflow_*')
Copy link
Member

@xabbuh xabbuh Aug 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// The supports options is useful only if you are using twig functions ('workflow_*')
// The "supports" option is useful only if you are using Twig functions ('workflow_*')

->supports(['App\Entity\PullRequest'])
->initialMarking(['start']);

Expand Down Expand Up @@ -252,33 +255,6 @@ Below is the configuration for the pull request state machine.
->to(['review']);
};

In a Symfony application using the
:ref:`default services.yaml configuration <service-container-services-load-example>`,
you can get this state machine by injecting the Workflow registry service::

// ...
use App\Entity\PullRequest;
use Symfony\Component\Workflow\Registry;

class SomeService
{
private $workflows;

public function __construct(Registry $workflows)
{
$this->workflows = $workflows;
}

public function someMethod(PullRequest $pullRequest)
{
$stateMachine = $this->workflows->get($pullRequest, 'pull_request');
$stateMachine->apply($pullRequest, 'wait_for_review');
// ...
}

// ...
}

Symfony automatically creates a service for each workflow (:class:`Symfony\\Component\\Workflow\\Workflow`)
or state machine (:class:`Symfony\\Component\\Workflow\\StateMachine`) you
have defined in your configuration. This means that you can use ``workflow.pull_request``
Expand Down