-
Notifications
You must be signed in to change notification settings - Fork 58
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
Listener per graph #38
Comments
Hey there, I haven't found the time to answer the other issue, but this one is simpler I think. :) Personally I would avoid using the POST_TRANSITION because checking the graph type each time would be unnecessary as you said. I think you can get use an 'after' => [
'from_locked' => [
'from' => 'locked',
'do' => ['object', 'removePersonInCharge'],
],
], After any transition that goes away from the |
If you don't want to create a 'do' => ['object', 'setAttribute'],
'args' => ['"person_in_charge"', 'null'], // notice the double quotes on the field The |
Wow, thanks. I did not realize that callbacks work that way with to/from as well. I guess I should read your documentation and the one of the original Sorry I did not get around to dive into your explanation to my other question, yet. Will do as soon as possible. Stay safe! |
Hi @sebdesign , me again with the constant questions. 😅
I'm trying to figure out how to listen to all
POST_TRANSITION
events for one specific graph. By your readme it seems to be either listening to allPOST_TRANSITION
events for all graphs via SMEvents::POST_TRANSITION inEventServiceProvider
or callbacks for every state transition one by one.The use case is filtering all transitions going away from one state of one specific graph in order to reset some property afterwards. E.g. there's a
locked
state that's associated with aperson_in_charge
field that has to be reset tonull
whenever the graph transitions away from thelocked
state.edit: if the answer is hooking up
after
callbacks for every single transition, that's completely fine. I was just wondering if there is some kind of wildcard feature that I'm missing in this regard.edit2: if nothing else, I could probably do something like:
but it would fire a lot of unnecessary listener calls (though I'm not entirely sure how events and listeners impact performance in that regard).
Cheers,
Martin
The text was updated successfully, but these errors were encountered: