Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Workfow] Rename current MarkingStore #20462

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

Merged
merged 1 commit into from
Nov 9, 2016

Conversation

lyrixx
Copy link
Member

@lyrixx lyrixx commented Nov 9, 2016

Q A
Branch? master
Bug fix? no
New feature? no
BC breaks? yes (in un-released branch)
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -
  • ScalarMarkingStore -> SingleStateMarkingStore
  • PropertyAccessorMarkingStore -> MultipleStateMarkingStore

And I also made optionnal the marking_store config, to let the
componant choose the best marking store depending on the type
(state_machine or workflow).


Note: I did that to ease the on-boarding

@Nyholm
Copy link
Member

Nyholm commented Nov 9, 2016

I like this change. It makes it easier to understand the differences between the two.

👍

@wouterj
Copy link
Member

wouterj commented Nov 9, 2016

👍 Lot more descriptive (still a bit confused by "MarkingStore" but it's probably more correct if you're into the workflow nets)

@Nyholm
Copy link
Member

Nyholm commented Nov 9, 2016

The term is "marking" from the Petri net and that is something we should not change. But "store".. if we are not happy with it we can maybe could consider renaming it to "Strategy"

@lyrixx
Copy link
Member Author

lyrixx commented Nov 9, 2016

Actually, I made the marking_store configuration optional.

So this is the minimal config:

Workflow:

framework:
    workflows:
        article:
            supports:
                - AppBundle\Entity\Article
            places:
                - draft
                - wait_for_journalist
                - approved_by_journalist
                - wait_for_spellchecker
                - approved_by_spellchecker
                - published
            transitions:
                request_review:
                    from: draft
                    to:
                        - wait_for_journalist
                        - wait_for_spellchecker
                journalist_approval:
                    from: wait_for_journalist
                    to: approved_by_journalist
                spellchecker_approval:
                    from: wait_for_spellchecker
                    to: approved_by_spellchecker
                publish:
                    from:
                        - approved_by_journalist
                        - approved_by_spellchecker
                    to: published

state machine:

        task:
            type: state_machine
            supports:
                - AppBundle\Entity\Task
            places:
                - backlog
                - in_progress
                - done
            transitions:
                processing:
                    from: backlog
                    to: in_progress
                done:
                    from: in_progress
                    to: done

As you can see, we never talk about the marking store.


About the class name: it really save / get the Marking from a POPO. So I prefer MarkingStore to MarkingStrategy.

@Nyholm
Copy link
Member

Nyholm commented Nov 9, 2016

Im also fine with "store". I just tried to consider the alternatives because Wouter pointed it out.

@nicolas-grekas
Copy link
Member

👍

@lyrixx lyrixx force-pushed the workflow-renaming branch from 7aa1564 to 10f3aee Compare November 9, 2016 14:29
@@ -16,17 +16,17 @@
use Symfony\Component\Workflow\Marking;

/**
* PropertyAccessorMarkingStore.
* MultipleStateMarkingStore.
Copy link
Member

Choose a reason for hiding this comment

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

You should describe the class instead of just using the class name, which does not really help.

Copy link
Member Author

Choose a reason for hiding this comment

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

I updated the wording.

@lyrixx lyrixx force-pushed the workflow-renaming branch 3 times, most recently from a1dc444 to 0c1cba2 Compare November 9, 2016 15:16
@fabpot
Copy link
Member

fabpot commented Nov 9, 2016

👍

@javiereguiluz javiereguiluz added this to the 3.2 milestone Nov 9, 2016
* ScalarMarkingStore -> SingleStateMarkingStore
* PropertyAccessorMarkingStore -> MultipleStateMarkingStore

And I also made optionnal the `marking_store` config, to let the
componant choose the best marking store depending on the type
(state_machine or workflow).
@lyrixx lyrixx force-pushed the workflow-renaming branch from 0c1cba2 to 08464c9 Compare November 9, 2016 15:22
@lyrixx lyrixx merged commit 08464c9 into symfony:master Nov 9, 2016
lyrixx added a commit that referenced this pull request Nov 9, 2016
This PR was merged into the 3.2-dev branch.

Discussion
----------

[Workfow] Rename current MarkingStore

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | yes (in un-released branch)
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

* ScalarMarkingStore -> SingleStateMarkingStore
* PropertyAccessorMarkingStore -> MultipleStateMarkingStore

And I also made optionnal the `marking_store` config, to let the
componant choose the best marking store depending on the type
(state_machine or workflow).

---

Note: I did that to ease the on-boarding

Commits
-------

08464c9 [Workfow] Rename current MarkingStore
@lyrixx lyrixx deleted the workflow-renaming branch November 9, 2016 15:40
Nyholm added a commit to Nyholm/symfony-docs that referenced this pull request Nov 9, 2016
@stof
Copy link
Member

stof commented Nov 9, 2016

PropertyAccessorMarkingStore -> MultipleStateMarkingStore looks weird to me. This marking store is special because it relies on PropertyAccess. We could have other marking stores supporting multiple state and using a different implementation internally

@Nyholm
Copy link
Member

Nyholm commented Nov 9, 2016

You are technically correct but in practice it will be considered an edge case that you would need a MultipleStateMarkingStore that has another implementation than PropertyAccess.

Since it is rare, I'm fine with the name MultipleStateMarkingStore because it is way easier in to understand what it does.

* subject.
*
* This store deals with a "multiple state" Marking. It means a subject can be
* in many state at the same time.
Copy link
Member

Choose a reason for hiding this comment

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

states

{
private $property;
private $propertyAccessor;

/**
* PropertyAccessorMarkingStore constructor.
* MultipleStateMarkingStore constructor.
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't add any value.

* SingleStateMarkingStore stores the marking into a property of the subject.
*
* This store deals with a "single state" Marking. It means a subject can be in
* one and only state at the same time.
Copy link
Member

Choose a reason for hiding this comment

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

[...] and only one state [...]

{
private $property;
private $propertyAccessor;

/**
* ScalarMarkingStore constructor.
* SingleStateMarkingStore constructor.
Copy link
Member

Choose a reason for hiding this comment

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

same as above

@lyrixx
Copy link
Member Author

lyrixx commented Nov 10, 2016

@xabbuh Thanks for your review. I opened a new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants