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]
