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]
>
>
