Great question - I'm currently sorting out how to do this myself. I'm new to Cairngorm but have a decent amount of experience with Flex. Here are my thoughts:
Cairngorm promotes decoupling of the data model and front controller/commands from the view - which is appropriate for an MVC framework. Data binding supports this seperation (to an extent) and keeps the view up to date with the model in 'real time'. Data binding does not however provide an intuitive mechanism for reacting to cairngorm event results. So here a few solutions I've been tossing around:
1. Rely on Built in Flex events such as the datagrid's dataChange event to trigger a reaction.
2. Create view state variables in the model that, when changed through the front controller / commands, dispatch custom events from within their VO's / setters / ect.
3. Dispatch custom events directly from front controller / commands.
4. Create custom (or override existing) item renderers that self-transition / tween when changed as a result of data binding.
I'm sure there are other ways to do what we want, but I'm out of ideas. Which approach to take very well depends on how strongly you'd like to adhere to the MVC concept. Commands that dispatch generic events as their messages may or may not be acceptable to you - but they provide a straitforward way to trigger view related reactions without relying on data binding events. I'd be interested to know if Cairngorm 3 will address this challenge...
Let me know what you decide on if and when you make a choice!
Well what we've managed to do is through Binding we can change the view state in our command class, we amend the model in the command class this then changes the view which is bound to the model.
We also managed to create a sort function in the command to re-sort the ArrayCollection in the model, which again through databinding meant that the view was updated automatically.
I have seen that there is a way of sequencing events in the command class (http://cairngormdocs.org/blog/?p=27).
You should resist, and avoid, the temptation to couple your Commands with your Views, or dispatch events from the Command itself. The Command's purpose is to retrieve data and update your model. However, you can send a Responder object to the Command by extending the architecture a bit, so when the Command completes, it will automatically execute whatever is contained in the Responder object. By doing it this way, you delegate which code will be executed to the View, instead of hard-coding it inside your Command class.
Check out two of my blog articles that help explain the concept a bit better.
Since you are talking about dispatching events from a command to fire another command, maybe you should take a look to this post of Christophe Herreman.
It demonstrates how to chain events and works like a charm.
(Anyway I wouldn't dispatch an event from a command to resort a list)