Re: [flexcoders] Re: Cairngorm Model Locator
I think support for mixing event types is actually a recent change to the Command class provided by UM Cainrgorm (which your commands then subclass). If your version of the code is more than about a week old I would suggest pulling down the latest. Ben On Wed, Apr 30, 2008 at 10:54 AM, Douglas Knudsen <[EMAIL PROTECTED]> wrote: > > > On Wed, Apr 30, 2008 at 10:49 AM, Tom Chiverton < > [EMAIL PROTECTED]> wrote: > > > On Wednesday 30 Apr 2008, Ben Clinkinbeard wrote: > > > > Do I have to give both success and failure callbacks > > > Nope, only the first arg (result handler) is required > > > > But I can intermix UMEvent and Cairngorm Event as needed, right ? > > > Sure. Just to reiterate UMEvent extends CairngormEvent. > > DK > > > > > > > > > will it use one > > > > > > defined in the Command if (say) the failure callback is missing from > > the > > > UMEvent ? > > > > > > Exactly, that's a very common approach > > > > Rar. > > > > -- > > Tom Chiverton > > Helping to evangelistically reinvent front-end architectures > > on: http://thefalken.livejournal.com > > > > > > > > This email is sent for and on behalf of Halliwells LLP. > > > > Halliwells LLP is a limited liability partnership registered in England > > and Wales under registered number OC307980 whose registered office address > > is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. > > A list of members is available for inspection at the registered office. Any > > reference to a partner in relation to Halliwells LLP means a member of > > Halliwells LLP. Regulated by The Solicitors Regulation Authority. > > > > CONFIDENTIALITY > > > > This email is intended only for the use of the addressee named above and > > may be confidential or legally privileged. If you are not the addressee you > > must not read it and must not use any information contained in nor copy it > > nor inform any person other than Halliwells LLP or the addressee of its > > existence or contents. If you have received this email in error please > > delete it and notify Halliwells LLP IT Department on 0870 365 2500. > > > > For more information about Halliwells LLP visit www.halliwells.com. > > > > > > > > -- > > Flexcoders Mailing List > > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > Search Archives: > > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > > Links > > > > > > > > > > > -- > Douglas Knudsen > http://www.cubicleman.com > this is my signature, like it? > >
Re: [flexcoders] Re: Cairngorm Model Locator
On Wednesday 30 Apr 2008, Douglas Knudsen wrote: > > > > Do I have to give both success and failure callbacks > > > Nope, only the first arg (result handler) is required > > But I can intermix UMEvent and Cairngorm Event as needed, right ? > Sure. Just to reiterate UMEvent extends CairngormEvent. Cool. Over time we've tried a variety of thinks such as keeping the data in Model but using ChangeWatcher() in the view, and passing the View itself as a parameter of the Event, saving it in the Command, and calling a method on it in onResult(). UMEvent seems like a proper impl. of the latter, so it would be useful to introduce in newer versions or brand new projects. -- Tom Chiverton Helping to enthusiastically enhance high-yield design-patterns on: http://thefalken.livejournal.com This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Cairngorm Model Locator
On Wed, Apr 30, 2008 at 10:49 AM, Tom Chiverton < [EMAIL PROTECTED]> wrote: > On Wednesday 30 Apr 2008, Ben Clinkinbeard wrote: > > > Do I have to give both success and failure callbacks > > Nope, only the first arg (result handler) is required > > But I can intermix UMEvent and Cairngorm Event as needed, right ? Sure. Just to reiterate UMEvent extends CairngormEvent. DK > > > > > will it use one > > > > defined in the Command if (say) the failure callback is missing from the > > UMEvent ? > > > > Exactly, that's a very common approach > > Rar. > > -- > Tom Chiverton > Helping to evangelistically reinvent front-end architectures > on: http://thefalken.livejournal.com > > > > This email is sent for and on behalf of Halliwells LLP. > > Halliwells LLP is a limited liability partnership registered in England > and Wales under registered number OC307980 whose registered office address > is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. > A list of members is available for inspection at the registered office. Any > reference to a partner in relation to Halliwells LLP means a member of > Halliwells LLP. Regulated by The Solicitors Regulation Authority. > > CONFIDENTIALITY > > This email is intended only for the use of the addressee named above and > may be confidential or legally privileged. If you are not the addressee you > must not read it and must not use any information contained in nor copy it > nor inform any person other than Halliwells LLP or the addressee of its > existence or contents. If you have received this email in error please > delete it and notify Halliwells LLP IT Department on 0870 365 2500. > > For more information about Halliwells LLP visit www.halliwells.com. > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > Links > > > > -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it?
Re: [flexcoders] Re: Cairngorm Model Locator
On Wednesday 30 Apr 2008, gerhard.schlager wrote: > will be working with a lot of data. More than a few tens of meg ? If not, don't worry about it. > wouldn't be possible. Moreover, after some time he would be working > with old and inaccurate data since the data is already loaded on the > client so it won't load the new data from the server. Well, that's BlazDS's (or whatever's) job, not the Model. -- Tom Chiverton Helping to globally participate total design-patterns on: http://thefalken.livejournal.com This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Cairngorm Model Locator
On Wednesday 30 Apr 2008, Ben Clinkinbeard wrote: > > Do I have to give both success and failure callbacks > Nope, only the first arg (result handler) is required But I can intermix UMEvent and Cairngorm Event as needed, right ? > > will it use one > > defined in the Command if (say) the failure callback is missing from the > UMEvent ? > > Exactly, that's a very common approach Rar. -- Tom Chiverton Helping to evangelistically reinvent front-end architectures on: http://thefalken.livejournal.com This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: Cairngorm Model Locator
That's exactly what I was thinking about after I wrote my first message. I could do this in the Commands that load / unload the data. I have to check there if the data is already loaded anyway, so that could be the right place to track which window is using the data. --- In flexcoders@yahoogroups.com, "jer_ela" <[EMAIL PROTECTED]> wrote: > > I assume that when a new window is opened you have an event that > causes the data it needs to be loaded into the model locator. And you > will probably have a check to see if the data is already loaded so you > don't load it twice. > > Just keep track in the model of how many users there are for that > data. When windows close or otherwise no longer need the data have > them send an event that causes the counter to decrement. When it gets > to 0 you can unload the data.
[flexcoders] Re: Cairngorm Model Locator
--- In flexcoders@yahoogroups.com, Tom Chiverton <[EMAIL PROTECTED]> wrote: > Why do you need to do so ? I need to do this because there would be a lot of unused data in the client's memory. When a user works for hours with the application he will be working with a lot of data. Without freeing the memory that wouldn't be possible. Moreover, after some time he would be working with old and inaccurate data since the data is already loaded on the client so it won't load the new data from the server.
Re: [flexcoders] Re: Cairngorm Model Locator
> Do I have to give both success and failure callbacks Nope, only the first arg (result handler) is required > will it use one defined in the Command if (say) the failure callback is missing from the UMEvent ? Exactly, that's a very common approach Ben Sent via BlackBerry by AT&T -Original Message- From: Tom Chiverton <[EMAIL PROTECTED]> Date: Wed, 30 Apr 2008 09:25:40 To:flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: Cairngorm Model Locator On Wednesday 30 Apr 2008, Ben Clinkinbeard wrote: > 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. Do I have to give both success and failure callbacks, or will it use one defined in the Command if (say) the failure callback is missing from the UMEvent ? -- Tom Chiverton Helping to economically embrace back-end paradigms on: http://thefalken.livejournal.com This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links
Re: [flexcoders] Re: Cairngorm Model Locator
On Wednesday 30 Apr 2008, Ben Clinkinbeard wrote: > 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. Do I have to give both success and failure callbacks, or will it use one defined in the Command if (say) the failure callback is missing from the UMEvent ? -- Tom Chiverton Helping to economically embrace back-end paradigms on: http://thefalken.livejournal.com This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Cairngorm Model Locator
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 ,
> > > > > "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 S
Re: [flexcoders] Re: Cairngorm Model Locator
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 ,
> > > > "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 wo
Re: [flexcoders] Re: Cairngorm Model Locator
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 ,
> > > "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
> > > > > > > 40yahoogroups.com>, "Ben
> > >
> > > > > Clinkinbeard"
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > You definitely don't want your model keeping track of views
> > > using
> > > > > its data.
> > > > > >
Re: [flexcoders] Re: Cairngorm Model Locator
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 , "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
> > > > > 40yahoogroups.com>, "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
> > >
[flexcoders] Re: Cairngorm Model Locator
I assume that when a new window is opened you have an event that causes the data it needs to be loaded into the model locator. And you will probably have a check to see if the data is already loaded so you don't load it twice. Just keep track in the model of how many users there are for that data. When windows close or otherwise no longer need the data have them send an event that causes the counter to decrement. When it gets to 0 you can unload the data. --- In flexcoders@yahoogroups.com, "gerhard.schlager" <[EMAIL PROTECTED]> 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 >
Re: [flexcoders] Re: Cairngorm Model Locator
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 , "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 > > > 40yahoogroups.com>, "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]
[flexcoders] Re: Cairngorm Model Locator
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, "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 , "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] >
Re: [flexcoders] Re: Cairngorm Model Locator
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 , "Ben > Clinkinbeard" > > <[EMAIL PROTECTED]> 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 < > > [EMAIL PROTECTED]> 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]
[flexcoders] Re: Cairngorm Model Locator
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, "Ben Clinkinbeard" <[EMAIL PROTECTED]> 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 < > [EMAIL PROTECTED]> 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 > > > > > > >
