I came up against just this problem today and decided that the
sequence command wasn't appropriate for reasons similar to what
you've outlined below. The sequence is intrinsic in the actual
command classes which obviously makes them less reusable. In my app,
I wanted the idea of the command sequence to be at another level than
the commands themselves.
The solution I used was to create my own kind of sequence command,
which very simply just creates a list of other commands to be
executed in turn. It just keeps track of where it's up to and calls
the next command directly when the last one is done. I am not using
the event mechanism to call the commands.
This also requires that each command post a notification that it has
completed by firing a CommandComplete event which the sequence
commands listens on the event dispatcher for.
Hope that's useful to you.
Cheers,
Lach
On 20/12/2006, at 8:39 AM, thegiffman wrote:
Basically these are four different commands that should be executed in
sequence. And it makes sense from an architectural standpoint for
them to be separate - I can see wanting to query for fine data in
other situations than data set creation (like an update).
But here's the kicker - sequence commands don't really seem set up to
do this. I can't really get at the commands themselves to set the
next event with the constructor, since the front controller handles
all this. As such, the sequence command can really just do one action
- querying the back end for fine grain data will ALWAYS trigger an
event to add the data set.
To avoid this, I might include a flag in the event whether to stop or
go on to the next command. But this raises the question - can't I do
this anyway with a call to the event dispatcher? The value of having
sequence commands seems to be the ability to move to the next sequence
without the sequence being hardcoded. Yet this functionality doesn't
really exist - it is hidden by the front controller.
Could someone set me straight here?
