I thought it will be easy, but the Property Access does not support passing 2 arguments to a setter (super logic after all).

I don't know how to achieve this. Some randome ideas

1. Pass a PlaceAndContext to the POPO. but the BC layer will be impossible
2. do not rely on the the PropertyAccess anymore (but this imply re-code a (small) part of it in the workflow)
3. Add a MarkingStoreWithContext that does not rely on ProperyAccess and support only setXXXX method call (or with an Interface)
4. use the PropertyAccess to call setMarking then setContext

Have you other ideas ? What do you prefer ?

Actually I prefer the 2/
It quite easy. we only need to check if a property if public or if method marking() exist, or setMarking() exist. We could still use the PropertyAccessor for getMarking.

@lyrixx I think you are forgetting the fact that PropertyAccess takes a property path as input, not just a property name. Using PropertyAccess to read but a simpler implementation supporting only property names to write will not work.

Ah you are right. So we should go to 3/

What do you think ?

Just one question, as we do not mention we are using the Property Path component, is it a BC break a change the implementation ?

Not if nothing changes on the outside surface.What would be the user visible side effect?

@nicolas-grekas It could change someting to the end user if they use this kind of configuration:

framework:
    workflows:
        my_workflow:
            marking_store:
                type: multiple_state
                arguments: 
                    - 'property1.property2'

1. the arguments is documented there : https://symfony.com/doc/current/workflow/usage.html#creating-a-workflow
2. We don't explain that property1.property2 is supported.

So, if no one is using this feature (we can not be sure, I know, but really I doubt someone is using it), there are no difference for the end user

I case of you think it's a BC break, what do you think if the last commit?

@lyrixx thank you on coding this 👍

just a question: what is the aim behind MethodSingleStateMarkingStore? not sure to understand (i mainly use this component with single state)

also, how can we deal with sort of "validation" of the context?
optionresolver? interface? i think it could be safer to have this kind of control

The aim of MethodSingleStateMarkingStore is to be able to call $subject->setMarking($place, $context).

also, how can we deal with sort of "validation" of the context?

We will not validate the context. It's not the role of the workflow component to do that.

fair enough :) 👍

Here we go. I think this PR is ready.

Here is the diff the developer will have to do to use this new feature:
lyrixx/SFLive-Paris2016-Workflow#21

Note: I lost the integration with the framework bundle. I will fix it asap

Hi!

I finished this PR

But (in another PR) I would like to:

• deprecate SingleStateMarkingStore and MultipleStateMarkingStore. The new MethodMarkingStore could replace them for most a use case. If people are doing very complex thing, I would suggest using a service for that. We already have all infrastructure for it. My motivation are simplicity and expliciteness. the semantic configuration will me more explicit (instead of arguments: [true, marking] will could have arguments: {single_state: true, property: marking}). Thus I will be able to delete some code ❤️

• I don't really understand why we have the ValidateWorkflowsPass. It adds some complexity and I don't really see the use case here. @Nyholm Why did you added it ? We could directly validate the definition in the Framework Extension

What do you think ?

@noniagriconomie here we go. I rebased the PR and merged it. You can now test it and give me feedback. Thanks

an usage example base on https://github.com/lyrixx/SFLive-Paris2016-Workflow
(I will update the demo asap)

    /**
     * @Route("/apply-transition/{id}", methods={"POST"}, name="article_apply_transition")
     */
    public function applyTransitionAction(Request $request, Article $article)
    {
        try {
            $this->get('workflow.article')
                ->apply($article, $request->request->get('transition'), ['time' => time()]);

            $this->get('doctrine')->getManager()->flush();
        } catch (ExceptionInterface $e) {
            $this->get('session')->getFlashBag()->add('danger', $e->getMessage());
        }

        return $this->redirect(
            $this->generateUrl('article_show', ['id' => $article->getId()])
        );
    }

and the Article::setMarkingMethod:

    public function setMarking($marking, array $context = [])
    {
        $this->marking = $marking;
        dump($context);
    }

Here we go: How to use it and the demo

@lyrixx many thanks :)

Will of course test it and use it asap

Edit :
http://symfony-workflow-demo.herokuapp.com/task/show/1263 is broken (wanted to test on state machine also)

Also, can you have a second look at
symfony/symfony-docs#10751 ?

Thank you

Caught :)
See #30524

@lyrixx , why not making MethodMarkingStore final? I think, we should not encourage extending it, WDYT? On my practice, whenever I wanted to store markings differently, I always wrote a new implementation.

@vudaltsov Good idea 👍 I will do that :)

@lyrixx , I can do a PR for you, if you wish, have some time now!

oh yes. Please do :)

@noniagriconomie The demo has been fixed. Thanks for hint.