On Mon, Apr 21, 2008 at 9:20 PM, Josh McDonald <[EMAIL PROTECTED]> 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]> 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
