-
Notifications
You must be signed in to change notification settings - Fork 29
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
Add PermitDynamicIf and CanHandleTrigger methods. #20
Add PermitDynamicIf and CanHandleTrigger methods. #20
Conversation
Hi. I haven't had the time to update the documentation yet. But PermitDynamic already does the conditionals. I didn't do Second, However, for scenarios where you may just want to check, the I wish you had quickly just created an issue first before introducing a large commit. I feel bad that I may not be able to merge your significant effort again. :( I hope the above described design will addresses your scenarios. Please let me know if not, and I'd be happy to figure out the best path to a resolution. |
The guard predicates of the PermitIf etc. are there to determine if the trigger is valid (will be accepted) for the current state. I don't understand how you could use the NextStateRepresentationPredicate to determine if the trigger is valid for a current state. I understand the concern of CanHandleTrigger not being completely reliable in the scenario you present, and I think the Try* methods are a good solution to the issue. However In many scenarios the CanHandleTrigger test is very desirable. The CurrentPermittedTriggers collection does not test the guard predicates and thus does not provide the complete answer if a trigger will be honoured by the state machine. I am using (want to!) this state machine for a machine control application. I have state such as Idle, Executing, Paused etc. and triggers such as start, stop, pause, abort. The UI has buttons for Start, Stop, Pause, and Abort. The command handlers for the buttons call the CanHandleTrigger function for the appropriate trigger in the CanExecute method, and Fire the appropriate trigger in the Execute method. The guard predicates include checks for external conditions, such as doors closed, to prevent the user from trying to trigger a state transition if the machine is not able to honour it. The buttons are only enabled when the trigger is valid. I hope this clarifies why I think the the PermitDynamicIf and CanHandleTrigger methods are needed. |
This is an internal implementation detail that is never exposed outside. You really don't have to worry about how its handled for the purposes of doing From the usage perspective, adding conditions is easy: config.ForState(State.Stop)
.PermitDynamic(Trigger.Start, () => {
if (x == 0)
return State.Executing;
if (x == 1)
return State.Paused;
}); However, the So, with respect to how invalid triggers are handled are in the case of And if you want If you can adapt your commit for the same, that would be fantastic! Or I'll do these changes shortly. |
We will need CanHandleTrigger to be applicable to the PermitDynamic methods as well. That is why I added the PermitDynamicIf versions. The processing of the NextStateRepresentationPredicate in the CanHandleTrigger test would not be a desirable option (possible side effects). It would also make the API asymmetric, which is not desirable. |
Hi, sorry for the delay. Been extremely busy the last couple of weeks. Let me look into this this weekend, and will work out if this is the best way to achieve this. |
Hi, Regarding In the future, it would be great if you could open an issue, before modifying something that changes the core implementations. I understand that you probably, modified the code for your own operations, but I still feel bad that I was not able to merge your commit. |
The latest commit improves on the existing implementation of PermitDynamic, but changes its signature. All PermitDynamic methods now requires a func that returns a struct
|
Thanks, I have refactored one of my statemachines to use this pre-release version. I still think that having the PermitDynamicIf(...) would be desirable. In I think that the symmetry and orthogonality of the API would be improved Just my thoughts. Thank you for your efforts with this project. I do appreciate it. On Wed, Jun 17, 2015 at 6:23 AM, Prasanna V. Loganathar <
|
This is true. In fact, I'm rather of the opinion that its best that All the other Whereas, this way, all the conditional logic is clearly in one |
Thanks for doing the PermitDynamic implementation.
Here are the PermitDynamicIf and the CanHandleTrigger additions.
Thanks,
Keith