The last tip in this series was #5. The AnnounceFaultEvent (read more).
and now for tip #4:
The EventGenerator
The EventGenerator class provides a mechanism for defining sets of Events to be dispatched either sequentially or in parallel. The EventGenerator is defined declaratively in MXML. The generator provides an aggregated result response when the last event in the set has finished. It is still possible to attach responders to your individual events, as per normal in the UM Cairngorm world. (I’ll cover the Event-Responder relationship in more detail in a later post.)
There are couple of dependencies to the EventGenerator pattern. I consider these requirements good practice anyhow, but you should keep them in mind.
1. Define your event as a subclass of UMEvent not the Cairngorm Event Class
2. Define your command as a subclass of the UM Command class instead of implementing the Cairngorm ICommand interface.
3. Invoke super.execute() in your command execute method.
4. Invoke notifyCallers() in your command class when the command has finished executing.
And now for the example…
View the Application | View the Source | View the Docs
GetConfigurationEvent and DownloadSomethingEvent are basic Event classes that map to ConfigurationCommand and DownloadCommand, respectively. Both of these commands are implemented using the pattern I described in the dependency list above. Let’s take a look at the ConfigurationCommand as an example.
As you can see, ConfigurationCommand overrides the execute method and invokes the super execute method. Finally, when the delegate has returned a response notifyCaller is invoked. This is the signal the EventGenerator needs to know that the command has finished executing. If the generator is triggered as a sequential dispatcher notifyCaller() signals the generator to dispatch the next event in the series. If the generator is running in a parallel mode, notifyCaller() is used to keep a count of the event / command pairs that have finished. When all the events have signaled a finish, then the generator will dispatch the aggregated result signal.
The delegate used (EventGeneratorExampleDelegate) is fairly straight forward. It uses a URLLoader to download a couple of files from the same server that the application is deployed on.
Up next, #3 Data Translators.
This is great, thanks for posting this. I think we maybe able to use this in our application
No problem… glad it was a helpful post… more to come.
-adam
Keep them coming. I have a really good use case for this one where I need to fire off multiple events to get multiple combo box and list data, but I don’t want the screen showing up until they’re all completed. Nice that I can do the calls in parallel now.
Has there been any talk about adding the UM extensions to Cairngorm itself now that it’s been open-sourced?
I was wondering if you could show an example of attaching a view Callback to an event that is being triggered from an EventGenerator sequenced event. When I attach it using the callbacks property it never seems to hit the call back function I assigned.
@Duro
That’s coming up as the #1 tip… thanks for reading!
I was able to figure this one out (I was not implementing the notifyCallers() method when the command was done executing).
However, I have one more question. Is there something special that must be done to call the EventGenerator a second time. I am trying to refresh a view, and I have the Event sequence being dispatched each time the view refreshes, but no love on the second attempt. Seems like the sequence isn’t even running.
Thanks for this, Flater. You're a good man.
Dude This is going at the top of my "Must read later" list. I'm in the middle of another problem but came across this set of goodies.