Bart I could kiss you, if the big brothers hadn't made my sign a form
promising I wouldn't.
Thats exactly what I was looking for =)
Cheers!
-J
On Tue, Apr 22, 2008 at 3:37 PM, ben.clinkinbeard <
[EMAIL PROTECTED]> wrote:
> 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 <flexcoders%40yahoogroups.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]
> >
>
>
>
--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."
:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: [EMAIL PROTECTED]
