Cheers! -J
On Wed, Apr 30, 2008 at 1:27 PM, Ben Clinkinbeard < [EMAIL PROTECTED]> wrote: > http://code.google.com/p/flexcairngorm/source/browse > > > > On Tue, Apr 29, 2008 at 11:15 PM, Josh McDonald <[EMAIL PROTECTED]> wrote: > > > Is the source broweable online? I'd like to have a quick look at > > Callbacks.as > > > > I'm currently doing almost the exact same thing, although I simply have > > a custom base message with: > > > > public var failCallback : Function = function() : void {}; > > public var successCallback : Function = function() : void {}; > > > > And while it's crunch time right now, I'm interested in other > > implementation ideas as I'll be looking at refactoring this in the future to > > something a little nicer and more flex-like :) > > > > -J > > > > > > On Wed, Apr 30, 2008 at 11:24 AM, Ben Clinkinbeard < > > [EMAIL PROTECTED]> wrote: > > > > > Hi Josh, > > > > > > The implementation is roughly as follows. One of the additions is a > > > Callbacks class which implements IResponder, so on a basic level its just > > > a > > > container for a result and fault handler. Rather than your custom events > > > extending CairngormEvent, they extend UMEvent (which in turn extends > > > CairngormEvent), whose second parameter is of type Callbacks. Your view > > > callbacks (and your service handlers in your Commands) will receive a > > > ResultEvent or FaultEvent depending on the scenario, so if you want access > > > to the AsyncToken at that point you can pull it off of the event. > > > > > > The simple example that I think illustrates the usefulness of view > > > callbacks very well is that of disabling a portion of your UI during a > > > service call. So maybe its a login form and for obvious reasons you want > > > to > > > prevent interaction with the form between the time the submit button is > > > clicked and when you receive a response from the server. Storing something > > > like loginFormEnabled = true|false on your ModelLocator is not appropriate > > > or desirable, but there isn't much way around it if your view has no way > > > of > > > knowing when the call has finished. View callbacks solve this problem and > > > avoid having to store info like that on your model. Pseudo code is below, > > > hopefully this helps you understand the implementation a bit better. > > > > > > > > > private function handleSubmitBtnClick( event:MouseEvent ):void > > > { > > > loginForm.enabled = false; > > > new LoginEvent( userTxt.text, pwdTxt.text, new Callbacks( > > > handleLoginResult, handleLoginFault ) ).dispatch(); > > > } > > > > > > private function handleLoginResult( event:ResultEvent ):void > > > { > > > // handle result, etc > > > loginForm.enabled = true; > > > } > > > > > > private function handleLoginFault( event:FaultEvent ):void > > > { > > > // handle failure, etc > > > loginForm.enabled = true; > > > } > > > > > > > > > HTH, > > > Ben > > > > > > > > > On Tue, Apr 29, 2008 at 8:01 PM, Josh McDonald <[EMAIL PROTECTED]> > > > wrote: > > > > > > > I'm not using it so I can't comment on the implementation, but the > > > > callbacks are definitely a good idea. Letting each individual view know > > > > when > > > > whatever it has kicked off has either succeeded or failed in a standard > > > > way > > > > (whatever that may be) is great. > > > > > > > > It'd be nice if we could get an AsyncToken of some sorts from > > > > dispatchEvent() would be a much nicer way I think. Or even another > > > > method on > > > > EventDispatcher such as lastEventToken() : Token - although that's kinda > > > > nasty, and would have to rely on a ThreadLocal analogue if AS3 finds > > > > its way > > > > into a threaded environment. > > > > > > > > -J > > > > > > > > > > > > On Wed, Apr 30, 2008 at 9:40 AM, Bjorn Schultheiss < > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > Agreed > > > > > - Model has no reference to the view Classes. > > > > > > > > > > But it can still drive the creation of the view. > > > > > > > > > > For example, you might have an arrayCollection, the amount of > > > > > items in > > > > > the arrayCollection determine the amount of windows on display.. > > > > > The items within the arrayCollection may be the 'dataProviders' > > > > > for > > > > > each window, not necessarily a reference to the view classes but > > > > > still > > > > > responsible for driving the view. > > > > > > > > > > With regards to the additions to Cairngorm UM released, I'm still > > > > > not > > > > > sold on the benifits of all of them or the implementation. > > > > > > > > > > > > > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, > > > > > "Josh McDonald" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > The whole point of MVC is that the model knows *nothing* about > > > > > the view. > > > > > > Which is one of the reasons UM is a great extension to > > > > > Cairngorm. > > > > > > > > > > > > -J > > > > > > > > > > > > On Wed, Apr 30, 2008 at 8:46 AM, Bjorn Schultheiss < > > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > I think the problem is that the current flex framework > > > > > architecture > > > > > > > doesn't conceptually work well with Cairngorm. > > > > > > > There's too much logic encapsulated into the view. > > > > > > > > > > > > > > Ideally you would like to drive the entire app via the model. > > > > > > > > > > > > > > It would be ideal if your model was managing how many windows > > > > > are > > > > > > > currently open and therefore knows which data models to tear > > > > > down. > > > > > > > > > > > > > > --- In > > > > > > > flexcoders@yahoogroups.com<flexcoders%40yahoogroups.com><flexcoders% > > > > > 40yahoogroups.com>, "Ben > > > > > > > > > > > > Clinkinbeard" > > > > > > > > > > > > > > <ben.clinkinbeard@> wrote: > > > > > > > > > > > > > > > > You definitely don't want your model keeping track of views > > > > > using > > > > > > > its data. > > > > > > > > My 30 second recommendation would be to look into the UM > > > > > Cairngorm > > > > > > > > extensions as they can help you reduce the amount of clutter > > > > > that > > > > > > > needs to > > > > > > > > be stored on the/a model. Specifically view callbacks is the > > > > > feature > > > > > > > that > > > > > > > > helps enable that. Search flexcoders for additional > > > > > discussion of UM > > > > > > > > Cairngorm. > > > > > > > > > > > > > > > > HTH, > > > > > > > > Ben > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 29, 2008 at 12:24 PM, gerhard.schlager < > > > > > > > > gerhard.schlager@> wrote: > > > > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > I'm currently creating the software design for a large > > > > > application > > > > > > > > > which we are going to build using Flex 3, Cairngorm 2.2.1 > > > > > and > > > > > SabreAMF > > > > > > > > > (PHP). I have already created my first prove of concept, > > > > > however, I > > > > > > > > > have a few issues with Cairngorm's Model Locator. > > > > > > > > > > > > > > > > > > 1) How can I make sure that unused data gets removed from > > > > > the > > > > > Model > > > > > > > > > Locator? The simple solution would be to destroy the data > > > > > that > > > > > a view > > > > > > > > > loaded when the view gets closed. However, we are going to > > > > > use > > > > > flexmdi > > > > > > > > > and it's quite possible that one or more MDI windows are > > > > > using the > > > > > > > > > same data. The only solution I've come up so far is to > > > > > make > > > > > the Model > > > > > > > > > Locator aware of which window uses which data. Therefore > > > > > it > > > > > could free > > > > > > > > > the unused data when no view uses it anymore. Yet, this > > > > > could be a > > > > > > > > > very error-prone solution. Moreover, I would loose the > > > > > last bit of > > > > > > > > > loose coupling. So, I'm not sure if that's a good way to > > > > > handle this. > > > > > > > > > Well, the Model Locator itself is often seen as an > > > > > anti-pattern as > > > > > > > > > well ... > > > > > > > > > > > > > > > > > > 2) Should I really put everything into _one_ Model > > > > > Locator? I > > > > > guess > > > > > > > > > there could be quite a large number of public variables. > > > > > Our > > > > > > > > > application will have up to 50 different views and about > > > > > twice > > > > > as many > > > > > > > > > VO ... > > > > > > > > > > > > > > > > > > I'd be really grateful if somebody could enlighten my ;-) > > > > > or > > > > > if you > > > > > > > > > could give me some tips on how to solve those two > > > > > problems. > > > > > > > > > > > > > > > > > > Thanks in advance for your help. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Gerhard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > "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] > > > > > > > > > > > > > > > > -- > > "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]
