Gabriel did a great job of explaining some of the primary benefits of
the UM extensions, one of which is definitely to reduce the extent to
which ModelLocator is used as a dumping ground for data that really
doesn't belong on the global model.
As for the how, here are a couple of main points. UMEvent extends
CairngormEvent and has a handler:Callbacks parameter as the second
argument of its constructor. Callbacks is the class that bundles your
success and fault handlers (as well as a conflict handler but to be
honest I am not sure when that is triggered). The UM extensions also
allow you to dispatch CairngormEvents/UMEvents just like any other
event via dispatchEvent(). So an example might look like this.
private function handleLoginButtonClick( event:MouseEvent ):void
{
var userVO:UserVO = new UserVO( user.text, pwd.text );
// UMEvent subclass
var userEvent:UserEvent = new UserEvent( UserEvent.EVENT_ID, new
Callbacks( handleLoginSuccess, handleLoginFault ) );
userEvent.userVO = userVO;
dispatchEvent( userEvent );
}
HTH,
Ben
--- In flexcoders@yahoogroups.com, "Josh McDonald" <[EMAIL PROTECTED]> wrote:
>
> Thanks heaps for the info guys!
>
> Are the callbacks members of the UM Event or something? Like do you do
>
> event.success = myFunc;
>
> before you dispatchEvent() or something? Is there a copy of the api docs
> online I can poke around in? I'm just looking to add similar
functionality
> to our existing in-house framework so I'm not missing out on any
time-savers
> :)
>
> -J
>
> On Tue, Apr 22, 2008 at 1:40 PM, gabriel montagné <
> [EMAIL PROTECTED]> wrote:
>
> > On Mon, Apr 21, 2008 at 9:20 PM, Josh McDonald
<[EMAIL PROTECTED]<dznuts%40gmail.com>>
> > wrote:
> > > understanding of modern Cairngorm? Most of the docs I've found
online
> > seem
> >
> > This is a good place to start:
> > http://cairngormdocs.org
> >
> > > On Tue, Apr 22, 2008 at 1:17 PM, shaun
<[EMAIL PROTECTED]<shaun%40internode.on.net>>
> > wrote:
> > > > The model is changed by the result of the event handling and
the views
> > > > observe this.
> >
> > That is the stock cairngorm way of doing it. In cairngorm, the
> > FrontController is the only listener for all the cairngorm events. It
> > keeps a table of commands to use for each event type. When the front
> > controller listens to an event, it will run that command (which is the
> > one that has all the logic packed in it to change the model). It's
> > from the commands that you update the data on the models and all the
> > view, which are bound to it, will respond.
> >
> > The UM Event extension allows you to send an additional callback
> > object on that event (a callback being a couple of functions packed in
> > an object, one for success, one for faults) so that you can bypass
> > keeping data on the model that was going to be used just for letting
> > the original view that dispatched the event that whatever process it
> > initiated was finished. When the command has finished doing
> > whatever it was that it was doing, it will run the callback function
> > that will tell the original view "I'm done".
> >
> > It sounds a bit complicated but actually it isn't. The classic
> > example is a login form.. from the form you pack a UserVO into an
> > event and dispatch the event. Right there, from the view that
> > dispatched the event, you disable the login form. Using stock
> > cairngorm you would have to wait for the command to set a flag on the
> > model that would let the view know that login process was complete.
> > But this would mean that you have to keep that flag there for everyone
> > to see when only the original view that dispatched the event needed
> > it.
> > Using the UM event, you can send a callback to the command... the
> > command does it's thing and when it's done, it runs the success (or
> > fault, if it failed) function on the callback, letting the login view
> > know that it can re-enable the form or whatever without having to keep
> > that data on the model.
> >
> > --
> > gabriel montagné láscaris comneno
> > http://rojored.com
> > t/506.8392.2040
> >
> >
>
>
>
> --
> "Therefore, send not to know For whom the bell tolls. It tolls for
thee."
>
> :: Josh 'G-Funk' McDonald
> :: 0437 221 380 :: [EMAIL PROTECTED]
>
