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