EventCommandMap execution order - what's correct?
28 views
Skip to first unread message
Stray
Jul 24, 2012, 7:29:33 AM7/24/12
to robo...@googlegroups.com
If you map multiple commands, with guards and/or hooks, to the same event, the current order of execution is:
1. Event is mapped for injection.
2. All guards executed in the order in which they were mapped.
3. Commands that the guards approved are created, hooks are run on those commands.
4. Event is unmapped for injection.
5. All commands are executed, in the order in which they were mapped.
This order prevents the event injection from 'leaking' into any work your command does.
However, Neil Manuell had instinctively imagined that the order would be:
Guard checked -> Command Created -> Hooks run -> Command executed
for each consecutive command in the order in which they were created. So - crucially, the first command has executed before the second guard is created.
Neil had intended to provide some mappings in the first command mapped, which are then used by the guards and commands that come later.
As you can see on his thread in issues, I was initially not sure that it's correct to change things to do what he expected.
However - having slept on it, I think perhaps if that's the 'least surprising' behaviour, then that's what we should go for.
Of course there are ways to achieve either behaviour yourself by dispatching custom events etc, but I wanted to check with the group.
The increased overhead would be that the event would be unmapped and remapped for each command, as we don't want the event mapping to persist during command execution.
Thoughts? What did you imagine the execution order would be?
Stray
1. Event is mapped for injection.
2. All guards executed in the order in which they were mapped.
3. Commands that the guards approved are created, hooks are run on those commands.
4. Event is unmapped for injection.
5. All commands are executed, in the order in which they were mapped.
This order prevents the event injection from 'leaking' into any work your command does.
However, Neil Manuell had instinctively imagined that the order would be:
Guard checked -> Command Created -> Hooks run -> Command executed
for each consecutive command in the order in which they were created. So - crucially, the first command has executed before the second guard is created.
Neil had intended to provide some mappings in the first command mapped, which are then used by the guards and commands that come later.
As you can see on his thread in issues, I was initially not sure that it's correct to change things to do what he expected.
However - having slept on it, I think perhaps if that's the 'least surprising' behaviour, then that's what we should go for.
Of course there are ways to achieve either behaviour yourself by dispatching custom events etc, but I wanted to check with the group.
The increased overhead would be that the event would be unmapped and remapped for each command, as we don't want the event mapping to persist during command execution.
Thoughts? What did you imagine the execution order would be?
Stray
Neil Manuell
Jul 24, 2012, 7:59:50 AM7/24/12
to robo...@googlegroups.com
I think that my usage and assumptions were at the least influenced by the fluid builder expressing a more natural style. Which I find interesting in itself.
My personal view is that as long as the EventCommandMap lifecycle is well documented there is no problem. As Stray points out CommandFlow would be better optimised for the functionality I am intending.
Use the right tools for the right job.
Right?
--
You received this message because you are subscribed to the Google
Groups "Robotlegs" group.
To post to this group, send email to robo...@googlegroups.com
To unsubscribe from this group, send email to
robotlegs+...@googlegroups.com
for support visit http://knowledge.robotlegs.org
Stray
Jul 24, 2012, 8:05:47 AM7/24/12
to robo...@googlegroups.com
True - but if it turns out that almost everybody expects the same as you, we should support that rather than forcing people to RTFM :)
Reply all
Reply to author
Forward
0 new messages