Loading ...
Sorry, an error occurred while loading the content.
 

Re: [flexcoders] Re: What do you think of UM Cairngorm Extensions,especially for Modular Apps?

Expand Messages
  • gabriel montagné
    ... Yeah, on has to go over the code a bit to see how it works, but that EventGenerator is pretty flexible and easy to use once you understand how the
    Message 1 of 19 , Apr 13, 2008
      On Sun, Apr 13, 2008 at 10:50 AM, Doug McCune <doug@...> wrote:
      > we'll be pushing out more examples, especially of how to use the
      > EventGenerator since that's something I think a lot of people have
      > needed to do.

      Yeah, on has to go over the code a bit to see how it works, but that
      EventGenerator is pretty flexible and easy to use once you understand
      how the UMEvents, on which it relies, work.

      UMEvents are CairngormEvent subclasses that have this callbacks:Callbacks
      property. Callbacks are just a couple of functions packed together (under an
      agreed interface (mx.rpc.IResponder)) that the command, which was triggered by
      the event, can *call back* when it's done (or if it has failed)... letting
      know however actually was behind that callback object what happened. (From
      the flexcoders.com interview it seems that these were built to be able to let
      know the view that dispatched the event the result of the call without having
      to clutter the model with unnecesary data that was only going to be used to
      let that original view know what had happened anyways.)

      When you define and EventGenerator, you set the list of events you want to be
      dipatched. when you fire it off, the EventGenerator will take the first one,
      will set it's callbacks properties so that it (the EG) will know when the
      command is done, and the will dispatch it. If the EG is set to run in
      sequence, it will then wait for the command associated with the event to run
      the callback that lets it know that it can then run the next command; It'll
      then run it, and so on until it runs out of events.

      One can find, in a comment that doesn't show on the asdocs, the AS example
      provided by the author (there's another that uses mxml notation and
      preinstantiated events):

      <quote><code>
      // If any task/event fails, then abort the task processing entirely
      (e.g. trigger == "0")
      var parallelEvents :Array = [LoadUserProfileEvent,LoadMetaDataEvent];
      var parallelGen :EventGenerator = new
      EventGenerator(parallelEvents,null,0,"parallel");

      // Now, manually add the parallel generator into the list for the
      consecutive generator...
      var consecutiveTasks : Array = [LoadBundleEvent,
      parallelGen, LoadUserPreferencesEvent];

      var handlers : CallBacks = new
      Callbacks(whenAppIsReady, notifyUserOfError);
      var cmd : EventGenerator = new
      EventGenerator(consecutiveTasks,handlers,0);
      cmd.dispatch();
      </code></quote>

      For this to work, you have to make sure that, from the command that might be
      run from an event generated by this EventGenerator, once it is done, you call
      the appropriate callback on the event or else the EventGenerator will just sit
      there waiting forever. You can do something along these lines:

      if (_yourTypedUMEvent.callbacks) _yourTypedUMEvent.callbacks.result(null);
      // or _yourTypedUMEvent.callbacks.fault(info); // if something went wrong.

      Please note that it seems that this was designed with asynchronous commands in
      mind only; if you run a command that can send a result right away, you might
      get a racing condition bug which will produce a runtime error.

      EventGenerator will take UMEvent classes, instance or other EventGenerators,
      so you can nest them in arbitrarily interesting ways. Pretty cool.

      --
      gabriel montagné láscaris comneno
      http://rojored.com
      t/506.8392.2040
    Your message has been successfully submitted and would be delivered to recipients shortly.