-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[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
Conversation
b89c93a
to
7aa1564
Compare
I like this change. It makes it easier to understand the differences between the two. 👍 |
👍 Lot more descriptive (still a bit confused by "MarkingStore" but it's probably more correct if you're into the workflow nets) |
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" |
Actually, I made the 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. |
Im also fine with "store". I just tried to consider the alternatives because Wouter pointed it out. |
👍 |
7aa1564
to
10f3aee
Compare
@@ -16,17 +16,17 @@ | |||
use Symfony\Component\Workflow\Marking; | |||
|
|||
/** | |||
* PropertyAccessorMarkingStore. | |||
* MultipleStateMarkingStore. |
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.
You should describe the class instead of just using the class name, which does not really help.
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 updated the wording.
a1dc444
to
0c1cba2
Compare
👍 |
* 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).
0c1cba2
to
08464c9
Compare
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
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 |
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. |
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.
states
{ | ||
private $property; | ||
private $propertyAccessor; | ||
|
||
/** | ||
* PropertyAccessorMarkingStore constructor. | ||
* MultipleStateMarkingStore constructor. |
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.
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. |
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.
[...] and only one state [...]
{ | ||
private $property; | ||
private $propertyAccessor; | ||
|
||
/** | ||
* ScalarMarkingStore constructor. | ||
* SingleStateMarkingStore constructor. |
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.
same as above
And I also made optionnal the
marking_store
config, to let thecomponant choose the best marking store depending on the type
(state_machine or workflow).
Note: I did that to ease the on-boarding