Re: [Flashcoders] MVC style Correction
Hi all, Really pleased that my original question has generated so much positive discussion, debate and learning on MVC. For me it has certainly shed some light on different ways to implement it and probably some improvements or different approaches I could take in the future. Currently I connect them all together exactly as Ross has his set up in his first example. Although I may experiment with some slightly different approaches or try out a framework. Regards, David On 7 March 2012 07:25, Cor c...@chello.nl wrote: +1 Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of John McCormack Sent: dinsdag 6 maart 2012 21:30 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
yay me! Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 let go of even your longest held beliefs, the only truth is in observation. On Mar 7, 2012, at 10:27 AM, David Hunter wrote: Hi all, Really pleased that my original question has generated so much positive discussion, debate and learning on MVC. For me it has certainly shed some light on different ways to implement it and probably some improvements or different approaches I could take in the future. Currently I connect them all together exactly as Ross has his set up in his first example. Although I may experiment with some slightly different approaches or try out a framework. Regards, David On 7 March 2012 07:25, Cor c...@chello.nl wrote: +1 Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of John McCormack Sent: dinsdag 6 maart 2012 21:30 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
On 07/03/2012 15:37, Ross Sclafani wrote: yay me! Indeed! Your MVC introductory example was superb. Paul Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 let go of even your longest held beliefs, the only truth is in observation. On Mar 7, 2012, at 10:27 AM, David Hunter wrote: Hi all, Really pleased that my original question has generated so much positive discussion, debate and learning on MVC. For me it has certainly shed some light on different ways to implement it and probably some improvements or different approaches I could take in the future. Currently I connect them all together exactly as Ross has his set up in his first example. Although I may experiment with some slightly different approaches or try out a framework. Regards, David On 7 March 2012 07:25, Corc...@chello.nl wrote: +1 Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of John McCormack Sent: dinsdag 6 maart 2012 21:30 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Issues which have not been resolved has to do with how the logic is distributed amongst MVC partners. So if anyone comes across an example in which they are uncertain, please let us hear about it. On that subject, the book by Joel Hooks' and Lindsey Fallow: ActionScript Developers Guide to RobotLegs: http://shop.oreilly.com/product/0636920021216.do says... As to whether checking an email address is valid view logic or application logic, there's no fixed answer. A good filter is that if only the view classes care about this logic, it belongs in your view layer. If other parts of the application need to be checked or informed, it's controller code. John On 07/03/2012 15:50, Paul Andrews wrote: On 07/03/2012 15:37, Ross Sclafani wrote: yay me! Indeed! Your MVC introductory example was superb. Paul Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 let go of even your longest held beliefs, the only truth is in observation. On Mar 7, 2012, at 10:27 AM, David Hunter wrote: Hi all, Really pleased that my original question has generated so much positive discussion, debate and learning on MVC. For me it has certainly shed some light on different ways to implement it and probably some improvements or different approaches I could take in the future. Currently I connect them all together exactly as Ross has his set up in his first example. Although I may experiment with some slightly different approaches or try out a framework. Regards, David On 7 March 2012 07:25, Corc...@chello.nl wrote: +1 Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of John McCormack Sent: dinsdag 6 maart 2012 21:30 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
sounds about right. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 let go of even your longest held beliefs, the only truth is in observation. On Mar 7, 2012, at 11:29 AM, John McCormack wrote: As to whether checking an email address is valid view logic or application logic, there's no fixed answer. A good filter is that if only the view classes care about this logic, it belongs in your view layer. If other parts of the application need to be checked or informed, it's controller code. John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
So a view can possibly have its own MVC within it? As long as the view is the only one using the data? View Controller View Model View View Or am I interp. this incorrectly? Best, Karl On Mar 7, 2012, at 10:29 AM, John McCormack wrote: Issues which have not been resolved has to do with how the logic is distributed amongst MVC partners. So if anyone comes across an example in which they are uncertain, please let us hear about it. On that subject, the book by Joel Hooks' and Lindsey Fallow: ActionScript Developers Guide to RobotLegs: http://shop.oreilly.com/product/0636920021216.do says... As to whether checking an email address is valid view logic or application logic, there's no fixed answer. A good filter is that if only the view classes care about this logic, it belongs in your view layer. If other parts of the application need to be checked or informed, it's controller code. John On 07/03/2012 15:50, Paul Andrews wrote: On 07/03/2012 15:37, Ross Sclafani wrote: yay me! Indeed! Your MVC introductory example was superb. Paul Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 let go of even your longest held beliefs, the only truth is in observation. On Mar 7, 2012, at 10:27 AM, David Hunter wrote: Hi all, Really pleased that my original question has generated so much positive discussion, debate and learning on MVC. For me it has certainly shed some light on different ways to implement it and probably some improvements or different approaches I could take in the future. Currently I connect them all together exactly as Ross has his set up in his first example. Although I may experiment with some slightly different approaches or try out a framework. Regards, David On 7 March 2012 07:25, Corc...@chello.nl wrote: +1 Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of John McCormack Sent: dinsdag 6 maart 2012 21:30 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
I have an example of that. If you wish I can send it to you Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers Sent: woensdag 7 maart 2012 21:16 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction So a view can possibly have its own MVC within it? As long as the view is the only one using the data? View Controller View Model View View Or am I interp. this incorrectly? Best, Karl On Mar 7, 2012, at 10:29 AM, John McCormack wrote: Issues which have not been resolved has to do with how the logic is distributed amongst MVC partners. So if anyone comes across an example in which they are uncertain, please let us hear about it. On that subject, the book by Joel Hooks' and Lindsey Fallow: ActionScript Developers Guide to RobotLegs: http://shop.oreilly.com/product/0636920021216.do says... As to whether checking an email address is valid view logic or application logic, there's no fixed answer. A good filter is that if only the view classes care about this logic, it belongs in your view layer. If other parts of the application need to be checked or informed, it's controller code. John On 07/03/2012 15:50, Paul Andrews wrote: On 07/03/2012 15:37, Ross Sclafani wrote: yay me! Indeed! Your MVC introductory example was superb. Paul Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 let go of even your longest held beliefs, the only truth is in observation. On Mar 7, 2012, at 10:27 AM, David Hunter wrote: Hi all, Really pleased that my original question has generated so much positive discussion, debate and learning on MVC. For me it has certainly shed some light on different ways to implement it and probably some improvements or different approaches I could take in the future. Currently I connect them all together exactly as Ross has his set up in his first example. Although I may experiment with some slightly different approaches or try out a framework. Regards, David On 7 March 2012 07:25, Corc...@chello.nl wrote: +1 Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of John McCormack Sent: dinsdag 6 maart 2012 21:30 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
Instead of sending, everyone can get it here: www.codobyte.com/MVC.zip Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers Sent: woensdag 7 maart 2012 21:16 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction So a view can possibly have its own MVC within it? As long as the view is the only one using the data? View Controller View Model View View Or am I interp. this incorrectly? Best, Karl On Mar 7, 2012, at 10:29 AM, John McCormack wrote: Issues which have not been resolved has to do with how the logic is distributed amongst MVC partners. So if anyone comes across an example in which they are uncertain, please let us hear about it. On that subject, the book by Joel Hooks' and Lindsey Fallow: ActionScript Developers Guide to RobotLegs: http://shop.oreilly.com/product/0636920021216.do says... As to whether checking an email address is valid view logic or application logic, there's no fixed answer. A good filter is that if only the view classes care about this logic, it belongs in your view layer. If other parts of the application need to be checked or informed, it's controller code. John On 07/03/2012 15:50, Paul Andrews wrote: On 07/03/2012 15:37, Ross Sclafani wrote: yay me! Indeed! Your MVC introductory example was superb. Paul Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 let go of even your longest held beliefs, the only truth is in observation. On Mar 7, 2012, at 10:27 AM, David Hunter wrote: Hi all, Really pleased that my original question has generated so much positive discussion, debate and learning on MVC. For me it has certainly shed some light on different ways to implement it and probably some improvements or different approaches I could take in the future. Currently I connect them all together exactly as Ross has his set up in his first example. Although I may experiment with some slightly different approaches or try out a framework. Regards, David On 7 March 2012 07:25, Corc...@chello.nl wrote: +1 Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of John McCormack Sent: dinsdag 6 maart 2012 21:30 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
What he was asking was where does certain logic go, such as: where do you check whether an email address is valid. So if only the view cares about the valid email address, you can do so in the view, otherwise move the logic to the controller. It also depends on how strict you are about what a view can / cannot do. Some people (and frameworks) prefer to have no logic whatsoever in the view (dumb view) and have all the logic in the controller or in a go-between pattern: Observer / Mediator / Presenter - whichever fits their need. For instance PureMVC and RobotLegs use Mediators: http://puremvc.org/component/option,com_wrapper/Itemid,34/ http://www.robotlegs.org/diagram/ regards, Muzak - Original Message - From: Karl DeSaulniers k...@designdrumm.com To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Wednesday, March 07, 2012 9:15 PM Subject: Re: [Flashcoders] MVC style Correction So a view can possibly have its own MVC within it? As long as the view is the only one using the data? View Controller View Model View View Or am I interp. this incorrectly? Best, Karl On Mar 7, 2012, at 10:29 AM, John McCormack wrote: Issues which have not been resolved has to do with how the logic is distributed amongst MVC partners. So if anyone comes across an example in which they are uncertain, please let us hear about it. On that subject, the book by Joel Hooks' and Lindsey Fallow: ActionScript Developers Guide to RobotLegs: http://shop.oreilly.com/product/0636920021216.do says... As to whether checking an email address is valid view logic or application logic, there's no fixed answer. A good filter is that if only the view classes care about this logic, it belongs in your view layer. If other parts of the application need to be checked or informed, it's controller code. John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I see. Thanks. Karl On Mar 7, 2012, at 4:52 PM, Peter Ginneberge wrote: What he was asking was where does certain logic go, such as: where do you check whether an email address is valid. So if only the view cares about the valid email address, you can do so in the view, otherwise move the logic to the controller. It also depends on how strict you are about what a view can / cannot do. Some people (and frameworks) prefer to have no logic whatsoever in the view (dumb view) and have all the logic in the controller or in a go-between pattern: Observer / Mediator / Presenter - whichever fits their need. For instance PureMVC and RobotLegs use Mediators: http://puremvc.org/component/option,com_wrapper/Itemid,34/ http://www.robotlegs.org/diagram/ regards, Muzak - Original Message - From: Karl DeSaulniers k...@designdrumm.com To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Wednesday, March 07, 2012 9:15 PM Subject: Re: [Flashcoders] MVC style Correction So a view can possibly have its own MVC within it? As long as the view is the only one using the data? View Controller View Model View View Or am I interp. this incorrectly? Best, Karl On Mar 7, 2012, at 10:29 AM, John McCormack wrote: Issues which have not been resolved has to do with how the logic is distributed amongst MVC partners. So if anyone comes across an example in which they are uncertain, please let us hear about it. On that subject, the book by Joel Hooks' and Lindsey Fallow: ActionScript Developers Guide to RobotLegs: http://shop.oreilly.com/product/0636920021216.do says... As to whether checking an email address is valid view logic or application logic, there's no fixed answer. A good filter is that if only the view classes care about this logic, it belongs in your view layer. If other parts of the application need to be checked or informed, it's controller code. John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
@Ross The more and more we all talk about this, and I get to see examples, the more I would like to see a working example of yours. I really like the simplicity and flow of your idea and with your permission, like to try out your style of MVC based off your example. My idea is to leverage the MVC into just 3 classes M: V: and C: and nothing more. (I am probably crazy but this little itch I have now will not go away) But because I have a disconnect on how the MVC is applied to an actual application I can not get grips on where to start. I feel that ANY actionscript one creates should be simplistic in nature and I feel that for any project you can fit everything into just a model a view or a controller. Or at least I'd like to try and test my theory... :) Please dont call me crazy, you'll just be spinning your SWFWheels. PS: by no means am I saying that anyone else's examples are crude or wrong. I have no stance to say such. Just a heart felt feeling I have that amongst the confusion of how its done correctly, there is a simplistic solution that everyone may be overlooking. That NEO if you will. On Mar 5, 2012, at 6:05 PM, Karl DeSaulniers wrote: Thanks Cor. On Mar 5, 2012, at 4:26 AM, Cor wrote: @Karl, I just created my first MVC and it is still in progress... Lots of fun! This video helped me a lot! http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/ Unfortuneatly the tutor mentions Controller can update View, but that example is not included. If anyone can give me a little example of how that is done in MVC, don't hasitate. :-) best regards Cor van Dooren The Netherlands -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers Sent: maandag 27 februari 2012 11:19 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction That actually makes a lot of sense to me and I haven't written one MVC yet. Thanks for the break-down! In relation to what Henrik said about using adaptors, I see the sub controllers as the adaptors, but they are not actually adaptors, just sub controllers with targets to the main controller. Yes? Best, Karl On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote: thanks, its just how i do MVC it really get interesting when you follow a mitosis development pattern... You start with one model, controller, and view, add features to each in parallel, and as each class gets too big, you break them out into subcontrollers, submodels, and subviews. Then sub-sub. My projects have a triple-tree structure branching out from the core model, controller, and view classes finer granularity as you reach further in, and always broken into M, V, and C: Models contain properties only. they dispatch a CHANGE Event every time one of their properties change,. Views display properties of the model. they listen for the CHANGE Event, and update their appearance with the new values stored in the model every time it changes. Controllers manipulate properties of the model. Whether trigger by event handlers in the views, or internal timers or network activity, any command that sets any value of any property of the model is placed in a controller. Controllers might use other controllers to trigger changes in submodels outside its subdomain the project starts off very compact, then grows with its functionality as required, always growing out from the center so you never paint yourself into a corner then later to optimize, you can get specific about which submodel a particular view is listening to, in turn limiting the number of change events it receives to those actually represented in the view. all subcontrollers hold a reference to the root controller, so it is easy to target any node on the controller tree from anywhere inside of it. same with the model tree. some submodel properties can emit the CHANGE Event only on a local level, and not send the event up the hierarchy, isolating the scope of view updates An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. if the video its playing, the user clicks pause in the view, it tells the controller to pause the stream in the model, which notifies the views, so the Video is paused, and pause button becomes a play button. thats how i do MVC. data is stored in mvc.models, data is displayed in mvc.views, and data is manipulated in mvc.controllers. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347
RE: [Flashcoders] MVC style Correction
+1 !!! Oh, would I love to see this too!! Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers Sent: dinsdag 6 maart 2012 10:26 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction @Ross The more and more we all talk about this, and I get to see examples, the more I would like to see a working example of yours. I really like the simplicity and flow of your idea and with your permission, like to try out your style of MVC based off your example. My idea is to leverage the MVC into just 3 classes M: V: and C: and nothing more. (I am probably crazy but this little itch I have now will not go away) But because I have a disconnect on how the MVC is applied to an actual application I can not get grips on where to start. I feel that ANY actionscript one creates should be simplistic in nature and I feel that for any project you can fit everything into just a model a view or a controller. Or at least I'd like to try and test my theory... :) Please dont call me crazy, you'll just be spinning your SWFWheels. PS: by no means am I saying that anyone else's examples are crude or wrong. I have no stance to say such. Just a heart felt feeling I have that amongst the confusion of how its done correctly, there is a simplistic solution that everyone may be overlooking. That NEO if you will. On Mar 5, 2012, at 6:05 PM, Karl DeSaulniers wrote: Thanks Cor. On Mar 5, 2012, at 4:26 AM, Cor wrote: @Karl, I just created my first MVC and it is still in progress... Lots of fun! This video helped me a lot! http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/ Unfortuneatly the tutor mentions Controller can update View, but that example is not included. If anyone can give me a little example of how that is done in MVC, don't hasitate. :-) best regards Cor van Dooren The Netherlands -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers Sent: maandag 27 februari 2012 11:19 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction That actually makes a lot of sense to me and I haven't written one MVC yet. Thanks for the break-down! In relation to what Henrik said about using adaptors, I see the sub controllers as the adaptors, but they are not actually adaptors, just sub controllers with targets to the main controller. Yes? Best, Karl On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote: thanks, its just how i do MVC it really get interesting when you follow a mitosis development pattern... You start with one model, controller, and view, add features to each in parallel, and as each class gets too big, you break them out into subcontrollers, submodels, and subviews. Then sub-sub. My projects have a triple-tree structure branching out from the core model, controller, and view classes finer granularity as you reach further in, and always broken into M, V, and C: Models contain properties only. they dispatch a CHANGE Event every time one of their properties change,. Views display properties of the model. they listen for the CHANGE Event, and update their appearance with the new values stored in the model every time it changes. Controllers manipulate properties of the model. Whether trigger by event handlers in the views, or internal timers or network activity, any command that sets any value of any property of the model is placed in a controller. Controllers might use other controllers to trigger changes in submodels outside its subdomain the project starts off very compact, then grows with its functionality as required, always growing out from the center so you never paint yourself into a corner then later to optimize, you can get specific about which submodel a particular view is listening to, in turn limiting the number of change events it receives to those actually represented in the view. all subcontrollers hold a reference to the root controller, so it is easy to target any node on the controller tree from anywhere inside of it. same with the model tree. some submodel properties can emit the CHANGE Event only on a local level, and not send the event up the hierarchy, isolating the scope of view updates An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. if the video its playing, the user clicks pause in the view, it tells the controller to pause the stream
Re: [Flashcoders] MVC style Correction
Forgive me if I am wrong, but I watched that video and it confused me.
The gentleman started creating the view first then made the model and
had the interaction between the two
then went and created the controller and in creating the controller
took away some code from the view that the
model handled and gave it to the controller. He also had the view
having reference to the model and controller.
var model:Model = new Model();
var controller:Controller = new Controller(model);
var view:View = new View(model, controller);
shouldn't it be..
var controller:Controller = new Controller();
var model:Model = new Model(controller);
var view:View = new View(model);
?
Trying to wrap my head around this.
Thanks for this video though Cor!
It helped me see a real example so far of how to implement a MVC.
Best,
Karl
On Mar 5, 2012, at 7:00 AM, Cor wrote:
Thanks Paul,
In the documentation I read there is mostly the View telling the
Controller
an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/actions
cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like
this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener :
view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul
Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period.
Nor do I
think that the view should be calling methods of the controller class.
One of the main benefits of MVC is separation of concerns. Views
shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller
listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes
in the
model.
There are several ways to build the MVC pattern. The video shows one
way,
but really it shows a coupling that shouldn't be as tight as it is
and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to
control it -
no problem about that, but we should keep our MVC components as
separate
black boxes.
Paul
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one
MVC
yet.
Thanks for the break-down!
In relation to what Henrik said about using adaptors, I see the sub
controllers as the adaptors, but they are not actually adaptors, just
sub controllers with targets to the main controller.
Yes?
Best,
Karl
On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote:
thanks, its just how i do MVC
it really get interesting when you follow a mitosis development
pattern... You start with one model, controller, and view, add
features to each in parallel, and as each class gets too big, you
break them out into subcontrollers, submodels
RE: [Flashcoders] MVC style Correction
My guess is the view needs the reference to the controller, because it
invokes function in there to update the model through the controller.
I am not a OOP or MVC specialist, and know nothing more as showed in the
video, so don't shoot me!
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: dinsdag 6 maart 2012 11:08
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Forgive me if I am wrong, but I watched that video and it confused me.
The gentleman started creating the view first then made the model and had
the interaction between the two then went and created the controller and in
creating the controller took away some code from the view that the model
handled and gave it to the controller. He also had the view having reference
to the model and controller.
var model:Model = new Model();
var controller:Controller = new Controller(model); var view:View = new
View(model, controller);
shouldn't it be..
var controller:Controller = new Controller(); var model:Model = new
Model(controller); var view:View = new View(model);
?
Trying to wrap my head around this.
Thanks for this video though Cor!
It helped me see a real example so far of how to implement a MVC.
Best,
Karl
On Mar 5, 2012, at 7:00 AM, Cor wrote:
Thanks Paul,
In the documentation I read there is mostly the View telling the
Controller an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/a
ctions cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like
this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener :
view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul
Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period.
Nor do I
think that the view should be calling methods of the controller class.
One of the main benefits of MVC is separation of concerns. Views
shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller
listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes
in the
model.
There are several ways to build the MVC pattern. The video shows one
way,
but really it shows a coupling that shouldn't be as tight as it is
and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to
control it -
no problem about that, but we should keep our MVC components as
separate
black boxes.
Paul
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one
MVC
yet.
Thanks for the break
RE: [Flashcoders] MVC style Correction
You could ofcourse take another approach:
In the view:
dispatchEvent(new Event(View.YOURVIEWEVENT));
and in the Contoller:
View.addEventListener(View.YOURVIEWEVENT, callback);
So there is a loose coupling as Paul wrote.
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: dinsdag 6 maart 2012 11:08
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Forgive me if I am wrong, but I watched that video and it confused me.
The gentleman started creating the view first then made the model and had
the interaction between the two then went and created the controller and in
creating the controller took away some code from the view that the model
handled and gave it to the controller. He also had the view having reference
to the model and controller.
var model:Model = new Model();
var controller:Controller = new Controller(model); var view:View = new
View(model, controller);
shouldn't it be..
var controller:Controller = new Controller(); var model:Model = new
Model(controller); var view:View = new View(model);
?
Trying to wrap my head around this.
Thanks for this video though Cor!
It helped me see a real example so far of how to implement a MVC.
Best,
Karl
On Mar 5, 2012, at 7:00 AM, Cor wrote:
Thanks Paul,
In the documentation I read there is mostly the View telling the
Controller an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/a
ctions cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like
this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener :
view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul
Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period.
Nor do I
think that the view should be calling methods of the controller class.
One of the main benefits of MVC is separation of concerns. Views
shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller
listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes
in the
model.
There are several ways to build the MVC pattern. The video shows one
way,
but really it shows a coupling that shouldn't be as tight as it is
and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to
control it -
no problem about that, but we should keep our MVC components as
separate
black boxes.
Paul
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one
MVC
yet.
Thanks for the break-down
Re: [Flashcoders] MVC style Correction
Bang!
:)
On Mar 6, 2012, at 4:21 AM, Cor wrote:
My guess is the view needs the reference to the controller, because it
invokes function in there to update the model through the controller.
I am not a OOP or MVC specialist, and know nothing more as showed in
the
video, so don't shoot me!
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: dinsdag 6 maart 2012 11:08
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Forgive me if I am wrong, but I watched that video and it confused me.
The gentleman started creating the view first then made the model
and had
the interaction between the two then went and created the controller
and in
creating the controller took away some code from the view that the
model
handled and gave it to the controller. He also had the view having
reference
to the model and controller.
var model:Model = new Model();
var controller:Controller = new Controller(model); var view:View = new
View(model, controller);
shouldn't it be..
var controller:Controller = new Controller(); var model:Model = new
Model(controller); var view:View = new View(model);
?
Trying to wrap my head around this.
Thanks for this video though Cor!
It helped me see a real example so far of how to implement a MVC.
Best,
Karl
On Mar 5, 2012, at 7:00 AM, Cor wrote:
Thanks Paul,
In the documentation I read there is mostly the View telling the
Controller an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/
devnet/a
ctions cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like
this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener :
view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul
Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but
that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period.
Nor do I
think that the view should be calling methods of the controller
class.
One of the main benefits of MVC is separation of concerns. Views
shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller
listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes
in the
model.
There are several ways to build the MVC pattern. The video shows one
way,
but really it shows a coupling that shouldn't be as tight as it is
and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to
control it -
no problem about that, but we should keep our MVC components as
separate
black boxes.
Paul
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one
MVC
yet.
Thanks for the break
Re: [Flashcoders] MVC style Correction
I kind of like that.
I guess I am looking to the controller to do the event dispatching to
the model
the model to listening for the result. the view listening for changes
to the model.
On Mar 6, 2012, at 4:26 AM, Cor wrote:
You could ofcourse take another approach:
In the view:
dispatchEvent(new Event(View.YOURVIEWEVENT));
and in the Contoller:
View.addEventListener(View.YOURVIEWEVENT, callback);
So there is a loose coupling as Paul wrote.
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: dinsdag 6 maart 2012 11:08
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Forgive me if I am wrong, but I watched that video and it confused me.
The gentleman started creating the view first then made the model
and had
the interaction between the two then went and created the controller
and in
creating the controller took away some code from the view that the
model
handled and gave it to the controller. He also had the view having
reference
to the model and controller.
var model:Model = new Model();
var controller:Controller = new Controller(model); var view:View = new
View(model, controller);
shouldn't it be..
var controller:Controller = new Controller(); var model:Model = new
Model(controller); var view:View = new View(model);
?
Trying to wrap my head around this.
Thanks for this video though Cor!
It helped me see a real example so far of how to implement a MVC.
Best,
Karl
On Mar 5, 2012, at 7:00 AM, Cor wrote:
Thanks Paul,
In the documentation I read there is mostly the View telling the
Controller an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/
devnet/a
ctions cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like
this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener :
view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul
Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but
that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period.
Nor do I
think that the view should be calling methods of the controller
class.
One of the main benefits of MVC is separation of concerns. Views
shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller
listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes
in the
model.
There are several ways to build the MVC pattern. The video shows one
way,
but really it shows a coupling that shouldn't be as tight as it is
and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to
control it -
no problem about that, but we should keep our MVC components as
separate
black boxes.
Paul
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash
Re: [Flashcoders] MVC style Correction
More like a CMV
Well its bedtime for me. Looking forward to more discussions.
Best,
Karl
On Mar 6, 2012, at 4:35 AM, Karl DeSaulniers wrote:
I kind of like that.
I guess I am looking to the controller to do the event dispatching
to the model
the model to listening for the result. the view listening for
changes to the model.
On Mar 6, 2012, at 4:26 AM, Cor wrote:
You could ofcourse take another approach:
In the view:
dispatchEvent(new Event(View.YOURVIEWEVENT));
and in the Contoller:
View.addEventListener(View.YOURVIEWEVENT, callback);
So there is a loose coupling as Paul wrote.
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: dinsdag 6 maart 2012 11:08
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Forgive me if I am wrong, but I watched that video and it confused
me.
The gentleman started creating the view first then made the model
and had
the interaction between the two then went and created the
controller and in
creating the controller took away some code from the view that the
model
handled and gave it to the controller. He also had the view having
reference
to the model and controller.
var model:Model = new Model();
var controller:Controller = new Controller(model); var view:View =
new
View(model, controller);
shouldn't it be..
var controller:Controller = new Controller(); var model:Model = new
Model(controller); var view:View = new View(model);
?
Trying to wrap my head around this.
Thanks for this video though Cor!
It helped me see a real example so far of how to implement a MVC.
Best,
Karl
On Mar 5, 2012, at 7:00 AM, Cor wrote:
Thanks Paul,
In the documentation I read there is mostly the View telling the
Controller an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/a
ctions cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like
this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener :
view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul
Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-
mvc/
Unfortuneatly the tutor mentions Controller can update View, but
that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period.
Nor do I
think that the view should be calling methods of the controller
class.
One of the main benefits of MVC is separation of concerns. Views
shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller
listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes
in the
model.
There are several ways to build the MVC pattern. The video shows one
way,
but really it shows a coupling that shouldn't be as tight as it is
and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to
control it -
no problem about that, but we should keep our MVC components as
separate
black boxes.
Paul
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun
Re: [Flashcoders] MVC style Correction
On 06/03/2012 10:35, Karl DeSaulniers wrote:
I kind of like that.
I guess I am looking to the controller to do the event dispatching to
the model
The controller manipulates the model, so it wouldn't really need to
dispatch events to it.
the model to listening for the result. the view listening for changes
to the model.
The model won't be listening for anything (though that is blurred as we
progress to model persistence, which may be asynchronous - saving across
a network, fetching data from a remote server, etc).
View allows user interaction,
View messages controller,
controller updates model,
view updates according to model changes.
On Mar 6, 2012, at 4:26 AM, Cor wrote:
You could ofcourse take another approach:
In the view:
dispatchEvent(new Event(View.YOURVIEWEVENT));
and in the Contoller:
View.addEventListener(View.YOURVIEWEVENT, callback);
So there is a loose coupling as Paul wrote.
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: dinsdag 6 maart 2012 11:08
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Forgive me if I am wrong, but I watched that video and it confused me.
The gentleman started creating the view first then made the model and
had
the interaction between the two then went and created the controller
and in
creating the controller took away some code from the view that the model
handled and gave it to the controller. He also had the view having
reference
to the model and controller.
var model:Model = new Model();
var controller:Controller = new Controller(model); var view:View = new
View(model, controller);
shouldn't it be..
var controller:Controller = new Controller(); var model:Model = new
Model(controller); var view:View = new View(model);
?
Trying to wrap my head around this.
Thanks for this video though Cor!
It helped me see a real example so far of how to implement a MVC.
Best,
Karl
On Mar 5, 2012, at 7:00 AM, Cor wrote:
Thanks Paul,
In the documentation I read there is mostly the View telling the
Controller an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/a
ctions cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like
this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener :
view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul
Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period.
Nor do I
think that the view should be calling methods of the controller class.
One of the main benefits of MVC is separation of concerns. Views
shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller
listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes
in the
model.
There are several ways to build the MVC pattern. The video shows one
way,
but really it shows a coupling that shouldn't be as tight as it is
and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to
control it -
no problem about that, but we should keep our MVC components
Re: [Flashcoders] MVC style Correction
I guess I am looking to the controller to do the event dispatching to the model the model to listening for the result. You don't normally do that. The controller talks to the model directly, so the controller knows the model. The model doesn't know neither view nor controller and dispatches events when it changes. There's some more explaning here on MSDN (1/3 down the page, under Solution): http://msdn.microsoft.com/en-us/library/ff649643.aspx Note that they refer to this page I posted earlier: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html - Original Message - From: Karl DeSaulniers k...@designdrumm.com To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Tuesday, March 06, 2012 11:35 AM Subject: Re: [Flashcoders] MVC style Correction I kind of like that. I guess I am looking to the controller to do the event dispatching to the model the model to listening for the result. the view listening for changes to the model. On Mar 6, 2012, at 4:26 AM, Cor wrote: You could ofcourse take another approach: In the view: dispatchEvent(new Event(View.YOURVIEWEVENT)); and in the Contoller: View.addEventListener(View.YOURVIEWEVENT, callback); So there is a loose coupling as Paul wrote. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I think a core concept got lost with MVC - the controller controls things. That is, it can directly update (control or talk to) a model and a view. A model should not directly update (control) anything except it's own data sources (remote or otherwise), and should only broadcast changes to anything listening, which should usually be just the controller, but sometimes a view may listen for changes too (then you have to put controller logic in the view, unless that particular view is a custom fit for the model data). A view similarly can be directly updated (controlled) by a controller, view controller, or presenter (I like that - it's a descriptive term for a view controller). For example, a controller for a list view changing the data source to a different category, or deleting an item from a view list because of remote changes, etc. A view should not directly control (or talk to) a model or a controller - it should broadcast changes to it's own state to whatever might be listening (and only controllers should be listening). So if the user hits the delete button on an item in a list view, the controller would receive a notification of some kind, and then directly tell the model to delete that item. (The glue between the controller and the view can be a bit messy in some APIs - especially the iOS API, with targets and all that.) To me having the model broadcast to the view is a shortcut - or even a short circuit - one that is justifiable in many cases, but it's good to understand that you are basically doing an end-run around the controller usually to just save some short term development time, or because you really do need a custom view for a particular model, rather than a generic view. That's how I understand MVC anyway. Kevin N. On 3/6/12 5:35 AM, Karl DeSaulniers wrote: I guess I am looking to the controller to do the event dispatching to the model the model to listening for the result. the view listening for changes to the model. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
+1 Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of John McCormack Sent: dinsdag 6 maart 2012 21:30 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction Absolutely agree, so thank you everyone - very much. Each day I look for more. As a result of people talking about RobotLegs I bought and today received Joel Hooks' ActionScript Developers Guide to RobotLegs. A new direction - which I am thankful for. John On 06/03/2012 18:57, Kevin Newman wrote: Also, this thread has helped to flesh out my understanding of MVC to a substantial degree. I love that. :-) Kevin N. On 3/6/12 11:40 AM, Kevin Newman wrote: That's how I understand MVC anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
@Karl, I just created my first MVC and it is still in progress... Lots of fun! This video helped me a lot! http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/ Unfortuneatly the tutor mentions Controller can update View, but that example is not included. If anyone can give me a little example of how that is done in MVC, don't hasitate. :-) best regards Cor van Dooren The Netherlands -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers Sent: maandag 27 februari 2012 11:19 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction That actually makes a lot of sense to me and I haven't written one MVC yet. Thanks for the break-down! In relation to what Henrik said about using adaptors, I see the sub controllers as the adaptors, but they are not actually adaptors, just sub controllers with targets to the main controller. Yes? Best, Karl On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote: thanks, its just how i do MVC it really get interesting when you follow a mitosis development pattern... You start with one model, controller, and view, add features to each in parallel, and as each class gets too big, you break them out into subcontrollers, submodels, and subviews. Then sub-sub. My projects have a triple-tree structure branching out from the core model, controller, and view classes finer granularity as you reach further in, and always broken into M, V, and C: Models contain properties only. they dispatch a CHANGE Event every time one of their properties change,. Views display properties of the model. they listen for the CHANGE Event, and update their appearance with the new values stored in the model every time it changes. Controllers manipulate properties of the model. Whether trigger by event handlers in the views, or internal timers or network activity, any command that sets any value of any property of the model is placed in a controller. Controllers might use other controllers to trigger changes in submodels outside its subdomain the project starts off very compact, then grows with its functionality as required, always growing out from the center so you never paint yourself into a corner then later to optimize, you can get specific about which submodel a particular view is listening to, in turn limiting the number of change events it receives to those actually represented in the view. all subcontrollers hold a reference to the root controller, so it is easy to target any node on the controller tree from anywhere inside of it. same with the model tree. some submodel properties can emit the CHANGE Event only on a local level, and not send the event up the hierarchy, isolating the scope of view updates An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. if the video its playing, the user clicks pause in the view, it tells the controller to pause the stream in the model, which notifies the views, so the Video is paused, and pause button becomes a play button. thats how i do MVC. data is stored in mvc.models, data is displayed in mvc.views, and data is manipulated in mvc.controllers. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote: BTW Ross, I thought your example was great. Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote: @Karl, I just created my first MVC and it is still in progress... Lots of fun! This video helped me a lot! http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/ Unfortuneatly the tutor mentions Controller can update View, but that example is not included. If anyone can give me a little example of how that is done in MVC, don't hasitate. :-) I don't think the controller should be updating the view. Period. Nor do I think that the view should be calling methods of the controller class. One of the main benefits of MVC is separation of concerns. Views shouldn't care about controllers, controllers should care about views. My views dispatch events about their changes and the controller listens for the events, not caring which view dispatched it. The controller updates the model, and the view listens for changes in the model. There are several ways to build the MVC pattern. The video shows one way, but really it shows a coupling that shouldn't be as tight as it is and the idea of a controller updating a view, is a no-no. Sometimes people use a micro-mvc architecture within a view to control it - no problem about that, but we should keep our MVC components as separate black boxes. Paul best regards Cor van Dooren The Netherlands -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers Sent: maandag 27 februari 2012 11:19 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction That actually makes a lot of sense to me and I haven't written one MVC yet. Thanks for the break-down! In relation to what Henrik said about using adaptors, I see the sub controllers as the adaptors, but they are not actually adaptors, just sub controllers with targets to the main controller. Yes? Best, Karl On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote: thanks, its just how i do MVC it really get interesting when you follow a mitosis development pattern... You start with one model, controller, and view, add features to each in parallel, and as each class gets too big, you break them out into subcontrollers, submodels, and subviews. Then sub-sub. My projects have a triple-tree structure branching out from the core model, controller, and view classes finer granularity as you reach further in, and always broken into M, V, and C: Models contain properties only. they dispatch a CHANGE Event every time one of their properties change,. Views display properties of the model. they listen for the CHANGE Event, and update their appearance with the new values stored in the model every time it changes. Controllers manipulate properties of the model. Whether trigger by event handlers in the views, or internal timers or network activity, any command that sets any value of any property of the model is placed in a controller. Controllers might use other controllers to trigger changes in submodels outside its subdomain the project starts off very compact, then grows with its functionality as required, always growing out from the center so you never paint yourself into a corner then later to optimize, you can get specific about which submodel a particular view is listening to, in turn limiting the number of change events it receives to those actually represented in the view. all subcontrollers hold a reference to the root controller, so it is easy to target any node on the controller tree from anywhere inside of it. same with the model tree. some submodel properties can emit the CHANGE Event only on a local level, and not send the event up the hierarchy, isolating the scope of view updates An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. if the video its playing, the user clicks pause in the view, it tells the controller to pause the stream in the model, which notifies the views, so the Video is paused, and pause button becomes a play button. thats how i do MVC. data is stored in mvc.models, data is displayed in mvc.views, and data is manipulated in mvc.controllers. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote: BTW Ross, I thought your example was great. Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
Thanks Paul,
In the documentation I read there is mostly the View telling the Controller
an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/actions
cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener : view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period. Nor do I
think that the view should be calling methods of the controller class.
One of the main benefits of MVC is separation of concerns. Views shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes in the
model.
There are several ways to build the MVC pattern. The video shows one way,
but really it shows a coupling that shouldn't be as tight as it is and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to control it -
no problem about that, but we should keep our MVC components as separate
black boxes.
Paul
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one MVC
yet.
Thanks for the break-down!
In relation to what Henrik said about using adaptors, I see the sub
controllers as the adaptors, but they are not actually adaptors, just
sub controllers with targets to the main controller.
Yes?
Best,
Karl
On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote:
thanks, its just how i do MVC
it really get interesting when you follow a mitosis development
pattern... You start with one model, controller, and view, add
features to each in parallel, and as each class gets too big, you
break them out into subcontrollers, submodels, and subviews. Then
sub-sub. My projects have a triple-tree structure branching out from
the core model, controller, and view classes
finer granularity as you reach further in, and always broken into M,
V, and C:
Models contain properties only. they dispatch a CHANGE Event every
time one of their properties change,.
Views display properties of the model. they listen for the CHANGE
Event, and update their appearance with the new values stored in the
model every time it changes.
Controllers manipulate properties of the model. Whether trigger by
event handlers in the views, or internal timers or network activity,
any command that sets any value of any property of the model is
placed in a controller. Controllers might use other controllers to
trigger changes in submodels outside its subdomain
the project starts off very compact
RE: [Flashcoders] MVC style Correction
tutor mentions Controller can update View, but that example is not included.
If anyone can give me a little example of how that is done in MVC, don't
hasitate
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Monday, March 05, 2012 5:27 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] MVC style Correction
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that example
is not included.
If anyone can give me a little example of how that is done in MVC, don't
hasitate. :-)
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one MVC yet.
Thanks for the break-down!
In relation to what Henrik said about using adaptors, I see the sub controllers
as the adaptors, but they are not actually adaptors, just sub controllers with
targets to the main controller.
Yes?
Best,
Karl
On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote:
thanks, its just how i do MVC
it really get interesting when you follow a mitosis development
pattern... You start with one model, controller, and view, add
features to each in parallel, and as each class gets too big, you
break them out into subcontrollers, submodels, and subviews. Then
sub-sub. My projects have a triple-tree structure branching out from
the core model, controller, and view classes
finer granularity as you reach further in, and always broken into M,
V, and C:
Models contain properties only. they dispatch a CHANGE Event every
time one of their properties change,.
Views display properties of the model. they listen for the CHANGE
Event, and update their appearance with the new values stored in the
model every time it changes.
Controllers manipulate properties of the model. Whether trigger by
event handlers in the views, or internal timers or network activity,
any command that sets any value of any property of the model is placed
in a controller. Controllers might use other controllers to trigger
changes in submodels outside its subdomain
the project starts off very compact, then grows with its functionality
as required, always growing out from the center so you never paint
yourself into a corner
then later to optimize, you can get specific about which submodel a
particular view is listening to, in turn limiting the number of change
events it receives to those actually represented in the view.
all subcontrollers hold a reference to the root controller, so it is
easy to target any node on the controller tree from anywhere inside of
it.
same with the model tree. some submodel properties can emit the CHANGE
Event only on a local level, and not send the event up the hierarchy,
isolating the scope of view updates
An MVC Example
FLVPlayback is an interesting MVC component:
it holds a NetStream as a model of the video
it holds a Video as a view of the Video
It acts as controller to set the model in motion by connecting it to a
stream
the ui is also a view of the video: the percent elapsed is represented
n the scrub bar, ther is a play button while paused, a pause button
while playing, then there are the time readouts..
if the video its playing,
the user clicks pause in the view,
it tells the controller to pause the stream in the model, which
notifies the views, so the Video is paused, and pause button becomes
a play button.
thats how i do MVC.
data is stored in mvc.models,
data is displayed in mvc.views, and
data is manipulated in mvc.controllers.
Ross P. Sclafani
design / technology / creative
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
http://www.linkedin.com/in/rosssclafani
[347] 204.5714
On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote:
BTW Ross, I thought your example was great.
Karl DeSaulniers
Design Drumm
http://designdrumm.com
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Re: [Flashcoders] MVC style Correction
That's a lot to follow.
As you show in your example, my views dispatch custom events *with
payloads*, where required, so if a slider value is changed I might
dispatch VOLUME_CHANGE with the changed value, or a reference to it.
Controllers need to pickup the events broadcast by the views. I use a
central policeman controller, and the views dispatch events from that.
Controllers aren't usually sitting on the display list, so dispatching
the event from the view would be a problem.
My views dispatch the events off the controller, but have no idea of the
internals of the controller. Generally my views find the controller and
model via singletons, not the constructor.
So a view change would be: Controller.getInstance().dispatchEvent(new
PayloadEvent(View.VOLUME_CHANGE,{volume:5}));
PayloadEvent is just an event that takes an object payload - a lazy way
to do custom events.
The controller knows nothing about the view, really.
Your example has the controller knowing about the view, but my
controller knows nothing about the views, so the controller listens to
events being dispatched from itself.
There are so many ways to skin this cat.
Paul
On 05/03/2012 13:00, Cor wrote:
Thanks Paul,
In the documentation I read there is mostly the View telling the Controller
an event has taken place.
The View holds e reference of the Model and the Controller.
Look at :
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/actions
cript/pdfs/ora_as3_design_patterns_ch12.pdf
on page number 429 (is the 11th page of this file)
So I have create this in my Document class like this:
var model:Model = Model.getInstance(); //Singleton
var controller:Controller = new Controller(model);
var view:View = new View(model, controller,
this.stage);
addChild(view);
To check if I understand you correctly, you would do something like this:
var model:Model = Model.getInstance(); //Singleton
var view:View = new View(model, this.stage);
var controller:Controller = new Controller(model,
view);
addChild(view);
And in the view instance, instead of my way:
private function btn_clickHandler(e:MouseEvent):void {
controller.setValueInModel(arrayButtons.indexOf(e.target));
}
private function btn_clickHandler(e:MouseEvent):void {
myPublicVar = arrayButtons.indexOf(e.target);
dispatchEvent(new Event(View.MY_CUSTOM_EVENT));
}
Ofcourse the Controller would then have a listener : view.addEventListener(
View.MY_CUSTOM_EVENT, callback_function);
Correct???
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews
Sent: maandag 5 maart 2012 13:31
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
On 05/03/2012 10:26, Cor wrote:
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that
example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
I don't think the controller should be updating the view. Period. Nor do I
think that the view should be calling methods of the controller class.
One of the main benefits of MVC is separation of concerns. Views shouldn't
care about controllers, controllers should care about views.
My views dispatch events about their changes and the controller listens for
the events, not caring which view dispatched it.
The controller updates the model, and the view listens for changes in the
model.
There are several ways to build the MVC pattern. The video shows one way,
but really it shows a coupling that shouldn't be as tight as it is and the
idea of a controller updating a view, is a no-no.
Sometimes people use a micro-mvc architecture within a view to control it -
no problem about that, but we should keep our MVC components as separate
black boxes.
Paul
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one MVC
yet.
Thanks for the break-down!
In relation to what Henrik said about using adaptors, I see the sub
controllers as the adaptors, but they are not actually adaptors, just
sub controllers with targets to the main controller.
Yes?
Best,
Karl
On Feb 27, 2012
Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
tutor mentions Controller can update View, but that example is not included.
If anyone can give me a little example of how that is done in MVC, don't
hasitate
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Monday, March 05, 2012 5:27 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] MVC style Correction
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that example
is not included.
If anyone can give me a little example of how that is done in MVC, don't
hasitate. :-)
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one MVC yet.
Thanks for the break-down!
In relation to what Henrik said about using adaptors, I see the sub controllers
as the adaptors, but they are not actually adaptors, just sub controllers with
targets to the main controller.
Yes?
Best,
Karl
On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote:
thanks, its just how i do MVC
it really get interesting when you follow a mitosis development
pattern... You start with one model, controller, and view, add
features to each in parallel, and as each class gets too big, you
break them out into subcontrollers, submodels, and subviews. Then
sub-sub. My projects have a triple-tree structure branching out from
the core model, controller, and view classes
finer granularity as you reach further in, and always broken into M,
V, and C:
Models contain properties only. they dispatch a CHANGE Event every
time one of their properties change,.
Views display properties of the model. they listen for the CHANGE
Event, and update their appearance with the new values stored in the
model every time it changes.
Controllers manipulate properties of the model. Whether trigger by
event handlers in the views, or internal timers or network activity,
any command that sets any value of any property of the model is placed
in a controller. Controllers might use other controllers to trigger
changes in submodels outside its subdomain
the project starts off very compact, then grows with its functionality
as required, always growing out from the center so you never paint
yourself into a corner
then later to optimize, you can get specific about which submodel a
particular view is listening to, in turn limiting the number of change
events it receives to those actually represented in the view.
all subcontrollers hold a reference to the root controller, so it is
easy to target any node on the controller tree from anywhere inside of
it.
same with the model tree. some submodel properties can emit the CHANGE
Event only on a local level, and not send the event up the hierarchy,
isolating the scope of view updates
An MVC Example
FLVPlayback is an interesting MVC component:
it holds a NetStream as a model of the video
it holds a Video as a view of the Video
It acts as controller to set the model in motion by connecting it to a
stream
the ui is also a view of the video: the percent elapsed is represented
n the scrub bar, ther is a play button while paused, a pause button
while playing, then there are the time readouts..
if the video its playing,
the user clicks pause in the view,
it tells the controller to pause the stream in the model, which
notifies the views, so the Video is paused, and pause button becomes
a play button.
thats how i do MVC.
data is stored in mvc.models,
data is displayed in mvc.views, and
data is manipulated in mvc.controllers.
Ross P. Sclafani
design / technology / creative
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
http://www.linkedin.com/in/rosssclafani
[347] 204.5714
On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote:
BTW Ross, I thought your example was great.
Karl DeSaulniers
Design Drumm
http://designdrumm.com
RE: [Flashcoders] MVC style Correction
It's the simplest form of MVC. I didn't say it was the best, I was just giving
the man what he asked for. :)
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews
Sent: Monday, March 05, 2012 9:11 AM
To: flashcoders@chattyfig.figleaf.com
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional views being
added or removed, requires that the controller be changed too. Any change to a
view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
tutor mentions Controller can update View, but that example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Monday, March 05, 2012 5:27 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] MVC style Correction
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that example
is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one MVC yet.
Thanks for the break-down!
In relation to what Henrik said about using adaptors, I see the sub
controllers as the adaptors, but they are not actually adaptors, just sub
controllers with targets to the main controller.
Yes?
Best,
Karl
On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote:
thanks, its just how i do MVC
it really get interesting when you follow a mitosis development
pattern... You start with one model, controller, and view, add
features to each in parallel, and as each class gets too big, you
break them out into subcontrollers, submodels, and subviews. Then
sub-sub. My projects have a triple-tree structure branching out from
the core model, controller, and view classes
finer granularity as you reach further in, and always broken into M,
V, and C:
Models contain properties only. they dispatch a CHANGE Event every
time one of their properties change,.
Views display properties of the model. they listen for the CHANGE
Event, and update their appearance with the new values stored in the
model every time it changes.
Controllers manipulate properties of the model. Whether trigger by
event handlers in the views, or internal timers or network activity,
any command that sets any value of any property of the model is
placed in a controller. Controllers might use other controllers to
trigger changes in submodels outside its subdomain
the project starts off very compact, then grows with its
functionality as required, always growing out from the center so you
never paint yourself into a corner
then later to optimize, you can get specific about which submodel a
particular view is listening to, in turn limiting the number of
change events it receives to those actually represented in the view.
all subcontrollers hold a reference to the root controller, so it is
easy to target any node on the controller tree from anywhere inside
of it.
same with the model tree. some submodel properties can emit the
CHANGE Event only on a local level, and not send the event up the
hierarchy, isolating the scope of view updates
An MVC Example
FLVPlayback is an interesting MVC component:
it holds a NetStream as a model of the video
it holds a Video as a view of the Video
It acts as controller to set the model in motion by connecting it to
a stream
the ui is also a view of the video: the percent elapsed is
represented n the scrub bar, ther is a play button while paused, a
pause button while playing, then there are the time readouts..
if the video its playing,
the user clicks pause in the view
Re: [Flashcoders] MVC style Correction
On 05/03/2012 14:13, Merrill, Jason wrote:
It's the simplest form of MVC. I didn't say it was the best, I was just giving
the man what he asked for. :)
Fair enough, but they do sell cigarettes with a health warning these
days.. ;-)
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews
Sent: Monday, March 05, 2012 9:11 AM
To: flashcoders@chattyfig.figleaf.com
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional views being
added or removed, requires that the controller be changed too. Any change to a
view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
tutor mentions Controller can update View, but that example is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Monday, March 05, 2012 5:27 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] MVC style Correction
@Karl,
I just created my first MVC and it is still in progress...
Lots of fun!
This video helped me a lot!
http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/
Unfortuneatly the tutor mentions Controller can update View, but that example
is not included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate. :-)
best regards
Cor van Dooren
The Netherlands
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl
DeSaulniers
Sent: maandag 27 februari 2012 11:19
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one MVC yet.
Thanks for the break-down!
In relation to what Henrik said about using adaptors, I see the sub controllers
as the adaptors, but they are not actually adaptors, just sub controllers with
targets to the main controller.
Yes?
Best,
Karl
On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote:
thanks, its just how i do MVC
it really get interesting when you follow a mitosis development
pattern... You start with one model, controller, and view, add
features to each in parallel, and as each class gets too big, you
break them out into subcontrollers, submodels, and subviews. Then
sub-sub. My projects have a triple-tree structure branching out from
the core model, controller, and view classes
finer granularity as you reach further in, and always broken into M,
V, and C:
Models contain properties only. they dispatch a CHANGE Event every
time one of their properties change,.
Views display properties of the model. they listen for the CHANGE
Event, and update their appearance with the new values stored in the
model every time it changes.
Controllers manipulate properties of the model. Whether trigger by
event handlers in the views, or internal timers or network activity,
any command that sets any value of any property of the model is
placed in a controller. Controllers might use other controllers to
trigger changes in submodels outside its subdomain
the project starts off very compact, then grows with its
functionality as required, always growing out from the center so you
never paint yourself into a corner
then later to optimize, you can get specific about which submodel a
particular view is listening to, in turn limiting the number of
change events it receives to those actually represented in the view.
all subcontrollers hold a reference to the root controller, so it is
easy to target any node on the controller tree from anywhere inside
of it.
same with the model tree. some submodel properties can emit the
CHANGE Event only on a local level, and not send the event up the
hierarchy, isolating the scope of view updates
An MVC Example
FLVPlayback is an interesting MVC component:
it holds a NetStream as a model of the video
it holds a Video as a view of the Video
It acts as controller to set the model in motion by connecting it to
a stream
the ui is also a view of the video: the percent elapsed is
represented n the scrub bar, ther is a play button while paused, a
pause button while playing, then there are the time readouts..
if the video its playing,
the user clicks pause
Re: [Flashcoders] MVC style Correction
i prefer to have the model update the views. preferably via event for loose coupling. the situations that a controller would alter a view in the versions of MVC i have studied are for things that are pure visual responses. like say a rollover: ROLL_OVER event on View -- calls onRollOver on controller -- sets highlight on View. Because the Flash SDK provides such a rich display API, I personally avoid this and leave any pure view event handling to the View internals to limit the public properties of Views. I could see a scenario where one such rollover needs to cause changes in multiple views, and this approach could be implemented, but i would normally rout these types updates through a submodel dedicated to UI. again, I value encapsulation above most other benefits of allowing the controller access to view properties, so i follow a standard unidirectional triangular flow. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
OK, I almost started changing my approach, but this confirms I shouldn't. I stopped smoking in 1978 but I still listen to all the warnings. :-) Thank you!! -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ross Sclafani Sent: maandag 5 maart 2012 15:37 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction i prefer to have the model update the views. preferably via event for loose coupling. the situations that a controller would alter a view in the versions of MVC i have studied are for things that are pure visual responses. like say a rollover: ROLL_OVER event on View -- calls onRollOver on controller -- sets highlight on View. Because the Flash SDK provides such a rich display API, I personally avoid this and leave any pure view event handling to the View internals to limit the public properties of Views. I could see a scenario where one such rollover needs to cause changes in multiple views, and this approach could be implemented, but i would normally rout these types updates through a submodel dedicated to UI. again, I value encapsulation above most other benefits of allowing the controller access to view properties, so i follow a standard unidirectional triangular flow. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I think a view can handle it's own rollover without concerning a controller. A controller is only there to manipulate the model on behlaf of the view. It has no interest in visuals. On 05/03/2012 14:36, Ross Sclafani wrote: i prefer to have the model update the views. preferably via event for loose coupling. the situations that a controller would alter a view in the versions of MVC i have studied are for things that are pure visual responses. like say a rollover: ROLL_OVER event on View -- calls onRollOver on controller -- sets highlight on View. Because the Flash SDK provides such a rich display API, I personally avoid this and leave any pure view event handling to the View internals to limit the public properties of Views. I could see a scenario where one such rollover needs to cause changes in multiple views, and this approach could be implemented, but i would normally rout these types updates through a submodel dedicated to UI. again, I value encapsulation above most other benefits of allowing the controller access to view properties, so i follow a standard unidirectional triangular flow. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
On 05/03/2012 14:43, Merrill, Jason wrote: Fair enough, but they do sell cigarettes with a health warning these days.. ;-) Trolling is so 2 years ago. :) I don't know why you consider the comment trolling. The OP wanted to know about how to do a technique and it's seems reasonable enough to suggest why it would also help them further by explaining why the technique is bad. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
On 05/03/2012 14:36, Ross Sclafani wrote: snip I could see a scenario where one such rollover needs to cause changes in multiple views, and this approach could be implemented, but i would normally rout these types updates through a submodel dedicated to UI. Do you have an example? I've always considered rollovers as direct feedback to the user on the element currently in focus. Any such use across multiple views eludes me for the minute. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
that is exactly how i roll.. but there are some schools that have the controller effecting all change, even temporary ones on the views. like i said, the flash SDK provides a great API for handling these things inside the views themselves. but you could imagine in a develpoment environment with no display list, using a controller to implement such a thing. in flash, though, it appears we take the same exact approach..so, you've got it perfect :D Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than a
Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
// VIEW
public class MyView implements IView {
public function update()(// do stuff);
}
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter,
Presenter doesn't know the view, only its interface.
regards,
Muzak
- Original Message -
From: Paul Andrews p...@ipauland.com
To: flashcoders@chattyfig.figleaf.com
Sent: Monday, March 05, 2012 3:11 PM
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
tutor mentions Controller can update View, but that example is not included.
If anyone can give me a little example of how that is done in MVC, don't
hasitate
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and
the presenter is controlling multiple views, or is that wrong?
On 05/03/2012 15:33, Peter Ginneberge wrote:
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than
a Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
// VIEW
public class MyView implements IView {
public function update()(// do stuff);
}
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter, Presenter doesn't know the view, only
its interface.
regards,
Muzak
- Original Message - From: Paul Andrews p...@ipauland.com
To: flashcoders@chattyfig.figleaf.com
Sent: Monday, March 05, 2012 3:11 PM
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
tutor mentions Controller can update View, but that example is not
included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
I am still at the most basic level, so I 'll stick to MVC for this moment.
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews
Sent: maandag 5 maart 2012 17:01
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and the
presenter is controlling multiple views, or is that wrong?
On 05/03/2012 15:33, Peter Ginneberge wrote:
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than
a Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
// VIEW
public class MyView implements IView {
public function update()(// do stuff); }
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.ht
ml
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.ht
ml#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.
html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkit
BestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter, Presenter doesn't know the view, only
its interface.
regards,
Muzak
- Original Message - From: Paul Andrews p...@ipauland.com
To: flashcoders@chattyfig.figleaf.com
Sent: Monday, March 05, 2012 3:11 PM
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
tutor mentions Controller can update View, but that example is not
included.
If anyone can give me a little example of how that is done in MVC,
don't hasitate
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
i think the flash display API prevents the need for all of these additional concerns and extra classes outside of Models Views and Controllers I also loathe Interfaces. the only time i use interfaces is to allow objects with two different class lineages to be used interchangeably. like a time that i needed AIR NativeWindows to be able to snap to DisplayObjects Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
If the model is updating the view, then it doesn't sound like you have a generic view at all. This can be appropriate in certain cases, but if you really want reusable View objects (like a generic scrolling text or image list view), they should be generic and abstracted from the underlying data sources (the model) - and have the data filtered through a data adapter, usually associated with the controller (or you can skip the adapter, and just bulk convert the entire model list data into generic view data, if it'll fit in memory or won't be updated in real time). In this version of MVC, to answer the original question - the controller sets up the view and wires the data source, but doesn't necessarily directly update the view (though that's who's job it is). In iOS these kinds of controllers are actually called view controllers - for maybe obvious reasons. :-) Kevin N. On 3/5/12 7:31 AM, Paul Andrews wrote: I don't think the controller should be updating the view. Period. Nor do I think that the view should be calling methods of the controller class. One of the main benefits of MVC is separation of concerns. Views shouldn't care about controllers, controllers should care about views. My views dispatch events about their changes and the controller listens for the events, not caring which view dispatched it. The controller updates the model, and the view listens for changes in the model. There are several ways to build the MVC pattern. The video shows one way, but really it shows a coupling that shouldn't be as tight as it is and the idea of a controller updating a view, is a no-no. Sometimes people use a micro-mvc architecture within a view to control it - no problem about that, but we should keep our MVC components as separate black boxes. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
On 05/03/2012 16:44, Kevin Newman wrote: If the model is updating the view, Not my model. My views listen for model change events. then it doesn't sound like you have a generic view at all. This can be appropriate in certain cases, but if you really want reusable View objects (like a generic scrolling text or image list view), they should be generic and abstracted from the underlying data sources (the model) - and have the data filtered through a data adapter, usually associated with the controller (or you can skip the adapter, and just bulk convert the entire model list data into generic view data, if it'll fit in memory or won't be updated in real time). I think that you're referring to the OTT pattern, favoured by many. I try and keep things simple. In this version of MVC, to answer the original question - the controller sets up the view and wires the data source, but doesn't necessarily directly update the view (though that's who's job it is). In iOS these kinds of controllers are actually called view controllers - for maybe obvious reasons. :-) Kevin N. On 3/5/12 7:31 AM, Paul Andrews wrote: I don't think the controller should be updating the view. Period. Nor do I think that the view should be calling methods of the controller class. One of the main benefits of MVC is separation of concerns. Views shouldn't care about controllers, controllers should care about views. My views dispatch events about their changes and the controller listens for the events, not caring which view dispatched it. The controller updates the model, and the view listens for changes in the model. There are several ways to build the MVC pattern. The video shows one way, but really it shows a coupling that shouldn't be as tight as it is and the idea of a controller updating a view, is a no-no. Sometimes people use a micro-mvc architecture within a view to control it - no problem about that, but we should keep our MVC components as separate black boxes. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
Fair enough, but they do sell cigarettes with a health warning these days.. ;-) Trolling is so 2 years ago. :) Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews Sent: Monday, March 05, 2012 9:33 AM To: flashcoders@chattyfig.figleaf.com Subject: Re: [Flashcoders] MVC style Correction On 05/03/2012 14:13, Merrill, Jason wrote: It's the simplest form of MVC. I didn't say it was the best, I was just giving the man what he asked for. :) Fair enough, but they do sell cigarettes with a health warning these days.. ;-) Jason Merrill Instructional Technology Architect II Bank of America Global Learning -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and the presenter is controlling multiple views, or is that
wrong?
Not in GWT, no.
There's one Presenter (or Controller) for the whole app.
And then there's an MVP triad for every view.
The app controller would then for instance listen to navigation events and be responsible for displaying the view matching the nav
event.
It would do that by creating a presenter and view instance, passing the view to
the presenter, e.g.
var p:HomePresenter = new HomePresenter(new HomeView());
// you could store p for later use, so to only create the presenter
(+view) once
The presenter's constructor argument is an interface:
public function HomePresenter(view:IHomeView) {}
By using a presenter and view interface, you're able to have very dumb views, swap them out, as long as they implement the required
interface.
This also allows for easier unit testing, in GWT even without the view
implementations at all.
=
@Ross:
I also loathe Interfaces.
the only time i use interfaces is to allow objects with two different class
lineages to be used interchangeably.
That's the whole point of the view interface and why I brought it up, as you can then swap views and your presenter is none the
wiser.
I admit, interfaces aren't used very often in Actionscript, in Java however, 99% of the time you're programming against interfaces
or abstract classes.
==
Anyway.. hope I'm not confusing people who are just getting into the whole
design pattern thing too much.
If you like reading, google:
mvc vs mvp vs mvvm
MVVM: http://en.wikipedia.org/wiki/Model_View_ViewModel
Martin Fowler on PresentationModel:
http://martinfowler.com/eaaDev/PresentationModel.html
regards,
Muzak
- Original Message -
From: Paul Andrews p...@ipauland.com
To: Flash Coders List flashcoders@chattyfig.figleaf.com
Sent: Monday, March 05, 2012 5:00 PM
Subject: Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and the presenter is controlling multiple views, or is that
wrong?
On 05/03/2012 15:33, Peter Ginneberge wrote:
The dependency with this is that any changes to the UI - additional views being added or removed, requires that the controller
be changed too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than a
Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
// VIEW
public class MyView implements IView {
public function update()(// do stuff);
}
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter, Presenter doesn't know the view, only its
interface.
regards,
Muzak
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Thanks Cor. On Mar 5, 2012, at 4:26 AM, Cor wrote: @Karl, I just created my first MVC and it is still in progress... Lots of fun! This video helped me a lot! http://pv3d.org/2009/02/11/actionscript-3-model-view-controller-mvc/ Unfortuneatly the tutor mentions Controller can update View, but that example is not included. If anyone can give me a little example of how that is done in MVC, don't hasitate. :-) best regards Cor van Dooren The Netherlands -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Karl DeSaulniers Sent: maandag 27 februari 2012 11:19 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction That actually makes a lot of sense to me and I haven't written one MVC yet. Thanks for the break-down! In relation to what Henrik said about using adaptors, I see the sub controllers as the adaptors, but they are not actually adaptors, just sub controllers with targets to the main controller. Yes? Best, Karl On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote: thanks, its just how i do MVC it really get interesting when you follow a mitosis development pattern... You start with one model, controller, and view, add features to each in parallel, and as each class gets too big, you break them out into subcontrollers, submodels, and subviews. Then sub-sub. My projects have a triple-tree structure branching out from the core model, controller, and view classes finer granularity as you reach further in, and always broken into M, V, and C: Models contain properties only. they dispatch a CHANGE Event every time one of their properties change,. Views display properties of the model. they listen for the CHANGE Event, and update their appearance with the new values stored in the model every time it changes. Controllers manipulate properties of the model. Whether trigger by event handlers in the views, or internal timers or network activity, any command that sets any value of any property of the model is placed in a controller. Controllers might use other controllers to trigger changes in submodels outside its subdomain the project starts off very compact, then grows with its functionality as required, always growing out from the center so you never paint yourself into a corner then later to optimize, you can get specific about which submodel a particular view is listening to, in turn limiting the number of change events it receives to those actually represented in the view. all subcontrollers hold a reference to the root controller, so it is easy to target any node on the controller tree from anywhere inside of it. same with the model tree. some submodel properties can emit the CHANGE Event only on a local level, and not send the event up the hierarchy, isolating the scope of view updates An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. if the video its playing, the user clicks pause in the view, it tells the controller to pause the stream in the model, which notifies the views, so the Video is paused, and pause button becomes a play button. thats how i do MVC. data is stored in mvc.models, data is displayed in mvc.views, and data is manipulated in mvc.controllers. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote: BTW Ross, I thought your example was great. Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Wanted to add that I use my own custom MVC micro-architecture which is based on (a mixture of) ARP and Cairngorm. Back when I was still developing in Flash (before I moved to Flex) I used ARP by Aral Balkan, which as far as I know was the first real MVC framework for Flash. Not even sure if there is another :) Unfortunatly ARP no longer exists, well at least it's no longer being developed/updated. There's still some info up on the osflash.org site: http://osflash.org/projects/arp But, the most important thing about ARP - at least to me - was the documentation that came with it and I can't seem to be able to get my hands on a working copy. The online version is down and the downloadable version (exe) for some reason doesn't work properly (I'm guessing it's hooked up to the online html version or something). http://osflash.org/downloads/arp/ARP_2.02_Manual.exe If someone can get it to work, I'd love to hear about it. The thing is, it contained a great explanation of how MVC applies to Flash. It explained all the relevant design patterns very well, including Model, View, Controller, Command and ServiceLocator. If you download the ARP sources + samples, you can still see how it works (and use it if you like). http://osflash.org/downloads/arp/ARP_2.02.zip regards, Muzak - Original Message - From: Peter Ginneberge p.ginnebe...@telenet.be To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Wednesday, February 29, 2012 4:25 PM Subject: Re: [Flashcoders] MVC style Correction Here's what I use. packages: - business Contains singleton with services (RemoteObject, WebService, HTTPService, SQLite), used by Command classes. - commands Contains commands that are executed by the Controller when a matching event is triggered. Commands are responsible for fetching data from server and storing it in the model. - control Contains AppController (singleton) that wires custom events to commands. - dto Date Transfer Objects (aka Value Objects). These get passed around with custom events and are stored in Model, etc. - events Custom events, usually dispatched by views. Controller listens for these events and executes matching command. - model App models. Dispatches change event when data changes. - view App views. == Where would you expect transfer object class dto package Where would you expect a custom event class? events package Where would you put a class that reads from and writes to the file system? commands package What about a class that holds string values to display ion dialog boxes, on buttons, etc? Is that part of the view or should it be defined in the model? Not in the view and certainly not in the model. Most likely a static utility class - package: utils regards, Muzak ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Found this FlashPaper swf that explains the ARP Pizza sample app: http://aralbalkan.com/downloads/FlashToFlex.swf The sample app is included in this download: http://osflash.org/downloads/arp/ARP_2.02.zip ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Here's what I use. packages: - business Contains singleton with services (RemoteObject, WebService, HTTPService, SQLite), used by Command classes. - commands Contains commands that are executed by the Controller when a matching event is triggered. Commands are responsible for fetching data from server and storing it in the model. - control Contains AppController (singleton) that wires custom events to commands. - dto Date Transfer Objects (aka Value Objects). These get passed around with custom events and are stored in Model, etc. - events Custom events, usually dispatched by views. Controller listens for these events and executes matching command. - model App models. Dispatches change event when data changes. - view App views. == Where would you expect transfer object class dto package Where would you expect a custom event class? events package Where would you put a class that reads from and writes to the file system? commands package What about a class that holds string values to display ion dialog boxes, on buttons, etc? Is that part of the view or should it be defined in the model? Not in the view and certainly not in the model. Most likely a static utility class - package: utils regards, Muzak - Original Message - From: Mattheis, Erik (MIN-WSW) ematth...@webershandwick.com To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Monday, February 27, 2012 10:19 PM Subject: Re: [Flashcoders] MVC style Correction I've been putting all my class files in one of three folders, model, view, controller. I'm mostly concerned with making the code as easy to understand as possible. Where would you expect transfer object class - a class that just defines a set of values to pass as a group? Where would you expect a custom event class? Where would you put a class that reads from and writes to the file system? Air.File has methods that produce UI elements. What are benefits/drawbacks to writing the extra code to get File.browseForOpen() somewhere in the View? What about a class that holds string values to display ion dialog boxes, on buttons, etc? Is that part of the view or should it be defined in the model? _ _ _ ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
That actually makes a lot of sense to me and I haven't written one MVC yet. Thanks for the break-down! In relation to what Henrik said about using adaptors, I see the sub controllers as the adaptors, but they are not actually adaptors, just sub controllers with targets to the main controller. Yes? Best, Karl On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote: thanks, its just how i do MVC it really get interesting when you follow a mitosis development pattern... You start with one model, controller, and view, add features to each in parallel, and as each class gets too big, you break them out into subcontrollers, submodels, and subviews. Then sub-sub. My projects have a triple-tree structure branching out from the core model, controller, and view classes finer granularity as you reach further in, and always broken into M, V, and C: Models contain properties only. they dispatch a CHANGE Event every time one of their properties change,. Views display properties of the model. they listen for the CHANGE Event, and update their appearance with the new values stored in the model every time it changes. Controllers manipulate properties of the model. Whether trigger by event handlers in the views, or internal timers or network activity, any command that sets any value of any property of the model is placed in a controller. Controllers might use other controllers to trigger changes in submodels outside its subdomain the project starts off very compact, then grows with its functionality as required, always growing out from the center so you never paint yourself into a corner then later to optimize, you can get specific about which submodel a particular view is listening to, in turn limiting the number of change events it receives to those actually represented in the view. all subcontrollers hold a reference to the root controller, so it is easy to target any node on the controller tree from anywhere inside of it. same with the model tree. some submodel properties can emit the CHANGE Event only on a local level, and not send the event up the hierarchy, isolating the scope of view updates An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. if the video its playing, the user clicks pause in the view, it tells the controller to pause the stream in the model, which notifies the views, so the Video is paused, and pause button becomes a play button. thats how i do MVC. data is stored in mvc.models, data is displayed in mvc.views, and data is manipulated in mvc.controllers. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote: BTW Ross, I thought your example was great. Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Ross Sclafani skriver: An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. Sadly, that is not true. First sentence of the manual page for the FLVPlayback class: FLVPlayback extends the Sprite class and wraps a VideoPlayer object. I don't have enough time to figure out how much this matters, but I assume that if you care you are better of reading the source code anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I'm not implying that the code even adheres to my personal MVC file structure, but its functional operation is a good example to illustrate my MVC paradigm. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 27, 2012, at 6:39 AM, Henrik Andersson he...@henke37.cjb.net wrote: Ross Sclafani skriver: An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. Sadly, that is not true. First sentence of the manual page for the FLVPlayback class: FLVPlayback extends the Sprite class and wraps a VideoPlayer object. I don't have enough time to figure out how much this matters, but I assume that if you care you are better of reading the source code anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
It was a good example of MVC Ross, I think Henrik was saying it should have been designed using MVC. I did see a nice example on a Microsoft poster using a clock with: analog and digital views; data in the model and the controller enabling the views etc. I am wondering what an adapter might get up to. John On 27/02/2012 13:17, Ross Sclafani wrote: I'm not implying that the code even adheres to my personal MVC file structure, but its functional operation is a good example to illustrate my MVC paradigm. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 27, 2012, at 6:39 AM, Henrik Anderssonhe...@henke37.cjb.net wrote: Ross Sclafani skriver: An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. Sadly, that is not true. First sentence of the manual page for the FLVPlayback class: FLVPlayback extends the Sprite class and wraps a VideoPlayer object. I don't have enough time to figure out how much this matters, but I assume that if you care you are better of reading the source code anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
In my world, an adapter is code I write to shoehorn code I didn't write into my framework. Code sealed in a third party SWF loaded by one of my views is a common candidate for an adapter. From a completely green field, I can't imagine needing to adapt any code I write to other code I've written. The name adapter implies two things that do not natively fit together. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 27, 2012, at 8:35 AM, John McCormack j...@easypeasy.co.uk wrote: It was a good example of MVC Ross, I think Henrik was saying it should have been designed using MVC. I did see a nice example on a Microsoft poster using a clock with: analog and digital views; data in the model and the controller enabling the views etc. I am wondering what an adapter might get up to. John On 27/02/2012 13:17, Ross Sclafani wrote: I'm not implying that the code even adheres to my personal MVC file structure, but its functional operation is a good example to illustrate my MVC paradigm. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 27, 2012, at 6:39 AM, Henrik Anderssonhe...@henke37.cjb.net wrote: Ross Sclafani skriver: An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. Sadly, that is not true. First sentence of the manual page for the FLVPlayback class: FLVPlayback extends the Sprite class and wraps a VideoPlayer object. I don't have enough time to figure out how much this matters, but I assume that if you care you are better of reading the source code anyway. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Well, not every object has to be a Model, a View, or a Controller. You can have your controller and view work with an instance of an adapter. You wouldn't want an adapter hanging out in the ether - but but your MVC objects could certainly have a uses a relationship to an adapter object. For example, you could have the controller create an adapter, wire it to the model, and set it to the dataSource of a view. This is clean because the view only needs to know how to get data from the adapter, it doesn't need to know anything about how the data lives in the model. Kevin N. On 2/26/12 8:45 PM, Karl DeSaulniers wrote: So is the basic construct to choose between a controller or multiple adaptors? It seems (to me) that a combination of the two is overkill. If you cant fit everything your trying to do within a MVC or MVA style pattern, your coding it wrong. Not setting flame, just inquiring. :) ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I've been putting all my class files in one of three folders, model, view, controller. I'm mostly concerned with making the code as easy to understand as possible. Where would you expect transfer object class - a class that just defines a set of values to pass as a group? Where would you expect a custom event class? Where would you put a class that reads from and writes to the file system? Air.File has methods that produce UI elements. What are benefits/drawbacks to writing the extra code to get File.browseForOpen() somewhere in the View? What about a class that holds string values to display ion dialog boxes, on buttons, etc? Is that part of the view or should it be defined in the model? _ _ _ Erik Mattheis | Weber Shandwick P: (952) 346.6610 M: (612) 377.2272 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I don't think that it makes sense to categorise every class in terms of the MVC trinity. Classes that implement the MVC pattern, sure, but not everything else. There's no need to put a sound processing class within the view class hierachy, even if the view uses it to play audio from the model. It would make it harder to see the actual classes involved in implementing views. A given class could be used inside a view and also in a controller. On 27/02/2012 21:19, Mattheis, Erik (MIN-WSW) wrote: I've been putting all my class files in one of three folders, model, view, controller. I'm mostly concerned with making the code as easy to understand as possible. Where would you expect transfer object class - a class that just defines a set of values to pass as a group? Where would you expect a custom event class? Where would you put a class that reads from and writes to the file system? Air.File has methods that produce UI elements. What are benefits/drawbacks to writing the extra code to get File.browseForOpen() somewhere in the View? What about a class that holds string values to display ion dialog boxes, on buttons, etc? Is that part of the view or should it be defined in the model? _ _ _ Erik Mattheis | Weber Shandwick P: (952) 346.6610 M: (612) 377.2272 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
My takes: I generally have a dataTypes folder at the same level as the MVC folder for 'transfer objects' I'd probably have an events folder at the same level in your case, but I can't see much of an argument for custom events in a properly architected MVC application. Since every write to the model throws a CHANGE event, the Entire app is evented in nature. What is an example of a custom event you'd like to support in your MVC app? I want to test my theory. As for Files, that screams controller to me. In an app that does file system manipulation via the OS, I'd likely have a fileSystemController class in my controller tree. The built-in browse for files UI is not likely something I'd concern my view tree with, I'd probably just treat it the same way I treat a web service: the controller talks to it and passes any result my app needs to access into the model. If I was making my own views to the file system, thats when I would involve the view tree. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com 347.204.5714 http://ross.sclafani.net http://www.twitter.com/rosssclafani On Feb 27, 2012, at 4:19 PM, Mattheis, Erik (MIN-WSW) ematth...@webershandwick.com wrote: I've been putting all my class files in one of three folders, model, view, controller. I'm mostly concerned with making the code as easy to understand as possible. entire Where would you expect transfer object class - a class that just defines a set of values to pass as a group? Where would you expect a custom event class? Where would you put a class that reads from and writes to the file system? Air.File has methods that produce UI elements. What are benefits/drawbacks to writing the extra code to get File.browseForOpen() somewhere in the View? What about a class that holds string values to display ion dialog boxes, on buttons, etc? Is that part of the view or should it be defined in the model? _ _ _ Erik Mattheis | Weber Shandwick P: (952) 346.6610 M: (612) 377.2272 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Kevin mentions... ...need to transform the format to fit the view, you would do that in the controller Henrik mentions... The data changing should be done in an adapter that the controller puts in between the model and the view. So the problems arise because the data that isn't quite what the model stores, or isn't quite what the views use. At the same time the controller shouldn't know about requirements of the model and views, but in this world of isolation and 'not knowing' about other things we need adapters that do know the details of other parties. Do all systems need adapters that convert data into the appropriate format? John On 26/02/2012 04:13, Karl DeSaulniers wrote: Why the extra step? Shouldn't the controller be that adaptor that is already between the model and the view? It's a MVC not a MVAC?? :) Karl On Feb 25, 2012, at 7:44 PM, Henrik Andersson wrote: Kevin Newman skriver: On 2/25/2012 8:00 PM, Paul Andrews wrote: Who is then? The model - but it depends on what you really mean by manipulate - if you are storing it (such as in a database) to be retrieved by the model at a later time, the model should do it. If you are channeling the data to a generic view, and need to transform the format to fit the view, you would do that in the controller. Kevin N. I disagree. The data changing should be done in an adapter that the controller puts in between the model and the view. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
John McCormack skriver: Kevin mentions... ...need to transform the format to fit the view, you would do that in the controller Henrik mentions... The data changing should be done in an adapter that the controller puts in between the model and the view. So the problems arise because the data that isn't quite what the model stores, or isn't quite what the views use. At the same time the controller shouldn't know about requirements of the model and views, but in this world of isolation and 'not knowing' about other things we need adapters that do know the details of other parties. Do all systems need adapters that convert data into the appropriate format? It is fine for the controller to know the identity of the formats involved. But understanding them is probably overkill. A well designed system will often have situations where the view and model use the same format, meaning that there is no need for any adapter. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Thanks Henrik, I guess things are much simpler if all parts know enough about the data format to be able to do what they need to do. I think I was imagining things more complicated than they need be. Thanks Ben, this was interesting... http://www.slideshare.net/RichardLord/application-frameworks-the-good-the-bad-the-ugly Robotlegs has good press. I wonder what people on this list prefer? John On 26/02/2012 14:07, Henrik Andersson wrote: John McCormack skriver: Kevin mentions... ...need to transform the format to fit the view, you would do that in the controller Henrik mentions... The data changing should be done in an adapter that the controller puts in between the model and the view. So the problems arise because the data that isn't quite what the model stores, or isn't quite what the views use. At the same time the controller shouldn't know about requirements of the model and views, but in this world of isolation and 'not knowing' about other things we need adapters that do know the details of other parties. Do all systems need adapters that convert data into the appropriate format? It is fine for the controller to know the identity of the formats involved. But understanding them is probably overkill. A well designed system will often have situations where the view and model use the same format, meaning that there is no need for any adapter. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
i've done stuff with my own informal model, view and controller separation. i've done things with pureMVC and now i've done a couple of things with robotlegs. i much prefer robotlegs, it's made me think of a lot of things differently, has reduced the size of my classes and i think enforces a better separation of the different tasks in your application which helps with code re-use. On 26 February 2012 18:20, John McCormack j...@easypeasy.co.uk wrote: Thanks Henrik, I guess things are much simpler if all parts know enough about the data format to be able to do what they need to do. I think I was imagining things more complicated than they need be. Thanks Ben, this was interesting... http://www.slideshare.net/**RichardLord/application-** frameworks-the-good-the-bad-**the-uglyhttp://www.slideshare.net/RichardLord/application-frameworks-the-good-the-bad-the-ugly Robotlegs has good press. I wonder what people on this list prefer? John On 26/02/2012 14:07, Henrik Andersson wrote: John McCormack skriver: Kevin mentions... ...need to transform the format to fit the view, you would do that in the controller Henrik mentions... The data changing should be done in an adapter that the controller puts in between the model and the view. So the problems arise because the data that isn't quite what the model stores, or isn't quite what the views use. At the same time the controller shouldn't know about requirements of the model and views, but in this world of isolation and 'not knowing' about other things we need adapters that do know the details of other parties. Do all systems need adapters that convert data into the appropriate format? It is fine for the controller to know the identity of the formats involved. But understanding them is probably overkill. A well designed system will often have situations where the view and model use the same format, meaning that there is no need for any adapter. __**_ Flashcoders mailing list Flashcoders@chattyfig.figleaf.**com Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/**mailman/listinfo/flashcodershttp://chattyfig.figleaf.com/mailman/listinfo/flashcoders __**_ Flashcoders mailing list Flashcoders@chattyfig.figleaf.**com Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/**mailman/listinfo/flashcodershttp://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I would say an adapter class is part of the controller, and it's ok for the controller to know about the formats of both the model and the view - it's job is to translate, and facilitate model data into generic view data (and back), even if all it does is setup a delegate, like an adapter. Many times that's honestly overkill - you might be able to get away with just taking a list of some stuff from the model, creating another list of view data, and copy the subset of data it needs (title, description, and id for one example) in a full list. It's often easier to do it this way. Other times, you might start from MVC, but your view isn't really all that generic (be careful if you find yourself here a lot, you might be spinning your wheels), so why not just pass a reference to the model, and skip all the API wrangling, adapters, etc. I consider it like optimizing my time, vs. optimizing the machine's time. But other times, there will be too much data to copy around, or you just wouldn't want to alloc all that memory just for duplicated data, cause that's slow on some hardware (or might use up more battery life, if you want to be kind to your users). That's where adapters comes in, to basically stream and wrap a subset of the full list of model data to the view as needed through an API, rather than all at once in a giant copy. The real problem seems to be that patterns are descriptive, more than prescriptive. So as implementations change, ideas tend to diverge, and sometimes differing patterns might even get described by other names. Maybe I've been describing MVA for example: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter Use what works, and doesn't drive you mad. That's what I say. :-) Kevin N. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
So is the basic construct to choose between a controller or multiple adaptors? It seems (to me) that a combination of the two is overkill. If you cant fit everything your trying to do within a MVC or MVA style pattern, your coding it wrong. Not setting flame, just inquiring. :) Karl On Feb 26, 2012, at 7:38 PM, Kevin Newman wrote: I would say an adapter class is part of the controller, and it's ok for the controller to know about the formats of both the model and the view - it's job is to translate, and facilitate model data into generic view data (and back), even if all it does is setup a delegate, like an adapter. Many times that's honestly overkill - you might be able to get away with just taking a list of some stuff from the model, creating another list of view data, and copy the subset of data it needs (title, description, and id for one example) in a full list. It's often easier to do it this way. Other times, you might start from MVC, but your view isn't really all that generic (be careful if you find yourself here a lot, you might be spinning your wheels), so why not just pass a reference to the model, and skip all the API wrangling, adapters, etc. I consider it like optimizing my time, vs. optimizing the machine's time. But other times, there will be too much data to copy around, or you just wouldn't want to alloc all that memory just for duplicated data, cause that's slow on some hardware (or might use up more battery life, if you want to be kind to your users). That's where adapters comes in, to basically stream and wrap a subset of the full list of model data to the view as needed through an API, rather than all at once in a giant copy. The real problem seems to be that patterns are descriptive, more than prescriptive. So as implementations change, ideas tend to diverge, and sometimes differing patterns might even get described by other names. Maybe I've been describing MVA for example: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter Use what works, and doesn't drive you mad. That's what I say. :-) Kevin N. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I have not created any MVC (I don't think) per se, so I am no authoritarian by any means. It just seems that when coding a paradigm, you want to keep it simple as possible so as to not confuse yourself or the paradigm. I would tend to agree that a controller should do just that... control. a view should be used to display and to send updates back to the controller depending on the user interaction. the model just sits there and gives and takes data, formating it for the view maybe or sending back errors for the controller. I think that if your model is as simple and streamlined as possible, it makes the job of the controller and view much easier. the controller is definitely the hardest worker of the three. I think also, that if you make your model aware of the others, it tends to start memory leaks. a plague of most smart phone apps and flash websites today. Kind of like a production artist trying to do art direction without telling the art director. Gets kinda messy. It can be done, but you may end up refunding the client. Open for thoughts.. Best, Karl On Feb 26, 2012, at 8:36 PM, Paul Andrews wrote: On 27/02/2012 01:45, Karl DeSaulniers wrote: So is the basic construct to choose between a controller or multiple adaptors? It seems (to me) that a combination of the two is overkill. If you cant fit everything your trying to do within a MVC or MVA style pattern, your coding it wrong. Not setting flame, just inquiring. :) Karl I'm with you Karl. I see models as a repository of data, modified by controllers, read by views. It's not necessary for controllers to have intimate knowledge of models, all that is required is that there is some kind of interface/ contract by which a controller can read and modify the data therein. I don't see the automatic need for any adaptor. It may be that one model has a different interface/contract to another, so a controller designed for one model could use an adaptor as an intermediary to another, but that is not what I understand as the core concept of MVC. Views updating models? No, not at all - they are simply reflections of the data model to the user, not something that modifies it. They only know about the data they show to the user, they don't modify it. The controls on a view message the controller, which may then alter the data in the model as a result, which then causes the view to update. MVC, in it's core is a control loop in a single direction. Control inputs change-Controller modifies Model- View shows updated model changes. People embellish the core model as they wish, but really the basic MVC pattern is simple and does not require adaptors. There could be adaptors, there could be multiple models, there could be views encapsulating their own mini-MVC. MVC can be extended and made more complex, but the basic principle is very simple. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
BTW Ross, I thought your example was great. On Feb 26, 2012, at 9:51 PM, Karl DeSaulniers wrote: I have not created any MVC (I don't think) per se, so I am no authoritarian by any means. It just seems that when coding a paradigm, you want to keep it simple as possible so as to not confuse yourself or the paradigm. I would tend to agree that a controller should do just that... control. a view should be used to display and to send updates back to the controller depending on the user interaction. the model just sits there and gives and takes data, formating it for the view maybe or sending back errors for the controller. I think that if your model is as simple and streamlined as possible, it makes the job of the controller and view much easier. the controller is definitely the hardest worker of the three. I think also, that if you make your model aware of the others, it tends to start memory leaks. a plague of most smart phone apps and flash websites today. Kind of like a production artist trying to do art direction without telling the art director. Gets kinda messy. It can be done, but you may end up refunding the client. Open for thoughts.. Best, Karl On Feb 26, 2012, at 8:36 PM, Paul Andrews wrote: On 27/02/2012 01:45, Karl DeSaulniers wrote: So is the basic construct to choose between a controller or multiple adaptors? It seems (to me) that a combination of the two is overkill. If you cant fit everything your trying to do within a MVC or MVA style pattern, your coding it wrong. Not setting flame, just inquiring. :) Karl I'm with you Karl. I see models as a repository of data, modified by controllers, read by views. It's not necessary for controllers to have intimate knowledge of models, all that is required is that there is some kind of interface/contract by which a controller can read and modify the data therein. I don't see the automatic need for any adaptor. It may be that one model has a different interface/contract to another, so a controller designed for one model could use an adaptor as an intermediary to another, but that is not what I understand as the core concept of MVC. Views updating models? No, not at all - they are simply reflections of the data model to the user, not something that modifies it. They only know about the data they show to the user, they don't modify it. The controls on a view message the controller, which may then alter the data in the model as a result, which then causes the view to update. MVC, in it's core is a control loop in a single direction. Control inputs change-Controller modifies Model- View shows updated model changes. People embellish the core model as they wish, but really the basic MVC pattern is simple and does not require adaptors. There could be adaptors, there could be multiple models, there could be views encapsulating their own mini-MVC. MVC can be extended and made more complex, but the basic principle is very simple. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
thanks, its just how i do MVC it really get interesting when you follow a mitosis development pattern... You start with one model, controller, and view, add features to each in parallel, and as each class gets too big, you break them out into subcontrollers, submodels, and subviews. Then sub-sub. My projects have a triple-tree structure branching out from the core model, controller, and view classes finer granularity as you reach further in, and always broken into M, V, and C: Models contain properties only. they dispatch a CHANGE Event every time one of their properties change,. Views display properties of the model. they listen for the CHANGE Event, and update their appearance with the new values stored in the model every time it changes. Controllers manipulate properties of the model. Whether trigger by event handlers in the views, or internal timers or network activity, any command that sets any value of any property of the model is placed in a controller. Controllers might use other controllers to trigger changes in submodels outside its subdomain the project starts off very compact, then grows with its functionality as required, always growing out from the center so you never paint yourself into a corner then later to optimize, you can get specific about which submodel a particular view is listening to, in turn limiting the number of change events it receives to those actually represented in the view. all subcontrollers hold a reference to the root controller, so it is easy to target any node on the controller tree from anywhere inside of it. same with the model tree. some submodel properties can emit the CHANGE Event only on a local level, and not send the event up the hierarchy, isolating the scope of view updates An MVC Example FLVPlayback is an interesting MVC component: it holds a NetStream as a model of the video it holds a Video as a view of the Video It acts as controller to set the model in motion by connecting it to a stream the ui is also a view of the video: the percent elapsed is represented n the scrub bar, ther is a play button while paused, a pause button while playing, then there are the time readouts.. if the video its playing, the user clicks pause in the view, it tells the controller to pause the stream in the model, which notifies the views, so the Video is paused, and pause button becomes a play button. thats how i do MVC. data is stored in mvc.models, data is displayed in mvc.views, and data is manipulated in mvc.controllers. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote: BTW Ross, I thought your example was great. Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I have really appreciated this thread too. The basic ideas of MVC seem straight forward enough, but the problems arise in implementing it. Disagreements about the roles inside MVC can really help us understand it. So if anyone has a specific example in which they struggled to determine the responsibilities of the roles, then it would be good to hear about it. John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
On 24/02/2012 15:15, Merrill, Jason wrote:
Maybe I'm off, but I don't think the controller should manipulate data.
Who is then?
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mattheis, Erik
(MIN-WSW)
Sent: Thursday, February 23, 2012 8:26 PM
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Ross Sclafaniross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code in question and looking in the appropriate branch.
Does it store data? It's in the model. Does it interpret and display data? Try
your views. Does it manipulate data? Look in the controller.
This thread has been useful, thanks all. I've a ton of questions regarding
judgment calls and below I post a class illustrating a few I've struggled with.
The comments are intended to be my questions/admissions of bafflement. I'm
unsure where in a MVC this class should go as its main purpose is to work with
the File class which itself has methods which retrieve
(File.applicationDirectory), interpret (File.exists) and display
(File.browseForOpen) data.
The class also is a dreaded example of allowing the view to listen directly to
the model for events, perhaps only because I've misguidedly decided to make it
part of the model as it has to do with copying and deleting a SQLite file used
in the app.
package mvc.model {
/* saveFileAs() saves a copy of a SQLite DB for the purposes of transferring
data to an instance of this app on another computer.
closeDBAndReplace() = replaces the db file if the user is importing data.
*/
import flash.events.EventDispatcher;
import flash.events.Event;
import flash.filesystem.File;
// class Data works with a SQLite DB
import mvc.model.Data;
// Where in a MVC should custom event classes // be located? I wish to pass my own
objects // along with events, usually Transfer Objects
// or a string to be displayed
import mvc.controller.CustomDataEvent;
public class ManipulateDBFile extends EventDispatcher {
private var _data:Data;
private var _sourceFile:File;
private var _copyToDirectory:File;
public function ManipulateDBFile(data:Data) {
_data = data;
}
public function saveFileAs() : void {
var docsDir:File = File.desktopDirectory;
// This creates a UI element. I would look for this code in the view!
docsDir.browseForDirectory('Save File in ...');
// This is asking a UI elemt to inform the Model directly. Big bad no?
docsDir.addEventListener(Event.SELECT, copyFile);
}
private function copyFile(e:Event):void {
_sourceFile = File.applicationStorageDirectory.resolvePath(msgDB.db);
_copyToDirectory = e.target.resolvePath(msgDB.db);
if (_copyToDirectory.exists) {
// Passing this event through the Controller seems to create complexity,
// or at least unnecessary lines of code. Is there an advantage gained by
// communicating to the view through the controller here?
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.FILE_ALREADY_EXISTS);
dispatchEvent(evt);
}
else {
replaceFile();
}
}
public function replaceFile() : void {
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.COPY_COMPLETE);
try {
_sourceFile.copyTo(_copyToDirectory, true);
dispatchEvent(evt);
}
catch (error:Error) {
evt.param = error.message;
dispatchEvent(evt);
}
_sourceFile = null;
_copyToDirectory = null;
}
public function closeDBAndReplace() : void {
// The file cannot be deleted if there is a SQLConnection to it.
// The class that is aware of a possible connection also does the
// deletion. But deleting the file seems to conceptually
// fit into this class better
_data.addEventListener(CustomDataEvent.DRILL_RESET, findFile, false, 0,
true);
_data.deleteDBFile();
}
private function findFile(e:CustomDataEvent) : void {
_data.removeEventListener(CustomDataEvent.DRILL_RESET, findFile, false);
var docsDir:File = File.desktopDirectory;
docsDir.browseForOpen('Select msgDB.db file ...');
docsDir.addEventListener(Event.SELECT, replaceDBFile);
}
private function replaceDBFile(e:Event):void {
var sourceFile:File = e.target as File;
var destination:File =
File.applicationStorageDirectory.resolvePath(msgDB.db);
try {
sourceFile.copyTo(destination, true);
dispatchEvent(new CustomDataEvent(CustomDataEvent.RESTART_REQUIRED));
}
catch (error:Error) {
trace(Error:, error.message);
}
}
}
}
On 2/17/12 6:07 PM, Ross Sclafaniross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code
Re: [Flashcoders] MVC style Correction
On 2/25/2012 8:00 PM, Paul Andrews wrote: Who is then? The model - but it depends on what you really mean by manipulate - if you are storing it (such as in a database) to be retrieved by the model at a later time, the model should do it. If you are channeling the data to a generic view, and need to transform the format to fit the view, you would do that in the controller. Kevin N. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Kevin Newman skriver: On 2/25/2012 8:00 PM, Paul Andrews wrote: Who is then? The model - but it depends on what you really mean by manipulate - if you are storing it (such as in a database) to be retrieved by the model at a later time, the model should do it. If you are channeling the data to a generic view, and need to transform the format to fit the view, you would do that in the controller. Kevin N. I disagree. The data changing should be done in an adapter that the controller puts in between the model and the view. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Why the extra step? Shouldn't the controller be that adaptor that is already between the model and the view? It's a MVC not a MVAC?? :) Karl On Feb 25, 2012, at 7:44 PM, Henrik Andersson wrote: Kevin Newman skriver: On 2/25/2012 8:00 PM, Paul Andrews wrote: Who is then? The model - but it depends on what you really mean by manipulate - if you are storing it (such as in a database) to be retrieved by the model at a later time, the model should do it. If you are channeling the data to a generic view, and need to transform the format to fit the view, you would do that in the controller. Kevin N. I disagree. The data changing should be done in an adapter that the controller puts in between the model and the view. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Different frameworks have different tweaks to the conventions. It's usually best to have a specific framework in mind when working on this. Eg. We do things differently in RubyonRails to RobotLegs. I've worked with Django in the past as well. It has hard blockers to keep logic getting into the views which occasionally make things incredibly difficult, whereas Rails doesn't force you as much. Django also calls controllers views and views templates, in case you're confused when reading their doco. The best thing is to go with a framework that has the developer culture and features that you like and then work with their way of doing things. It's particularly important to follow framework conventions as it makes upgrades much easier. On 26 February 2012 02:05, John McCormack j...@easypeasy.co.uk wrote: I have really appreciated this thread too. The basic ideas of MVC seem straight forward enough, but the problems arise in implementing it. Disagreements about the roles inside MVC can really help us understand it. So if anyone has a specific example in which they struggled to determine the responsibilities of the roles, then it would be good to hear about it. John __**_ Flashcoders mailing list Flashcoders@chattyfig.figleaf.**com Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/**mailman/listinfo/flashcodershttp://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
Maybe I'm off, but I don't think the controller should manipulate data.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mattheis, Erik
(MIN-WSW)
Sent: Thursday, February 23, 2012 8:26 PM
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Ross Sclafani ross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code in question and looking in the appropriate branch.
Does it store data? It's in the model. Does it interpret and display data? Try
your views. Does it manipulate data? Look in the controller.
This thread has been useful, thanks all. I've a ton of questions regarding
judgment calls and below I post a class illustrating a few I've struggled with.
The comments are intended to be my questions/admissions of bafflement. I'm
unsure where in a MVC this class should go as its main purpose is to work with
the File class which itself has methods which retrieve
(File.applicationDirectory), interpret (File.exists) and display
(File.browseForOpen) data.
The class also is a dreaded example of allowing the view to listen directly to
the model for events, perhaps only because I've misguidedly decided to make it
part of the model as it has to do with copying and deleting a SQLite file used
in the app.
package mvc.model {
/* saveFileAs() saves a copy of a SQLite DB for the purposes of transferring
data to an instance of this app on another computer.
closeDBAndReplace() = replaces the db file if the user is importing data.
*/
import flash.events.EventDispatcher;
import flash.events.Event;
import flash.filesystem.File;
// class Data works with a SQLite DB
import mvc.model.Data;
// Where in a MVC should custom event classes // be located? I wish to pass
my own objects // along with events, usually Transfer Objects
// or a string to be displayed
import mvc.controller.CustomDataEvent;
public class ManipulateDBFile extends EventDispatcher {
private var _data:Data;
private var _sourceFile:File;
private var _copyToDirectory:File;
public function ManipulateDBFile(data:Data) {
_data = data;
}
public function saveFileAs() : void {
var docsDir:File = File.desktopDirectory;
// This creates a UI element. I would look for this code in the view!
docsDir.browseForDirectory('Save File in ...');
// This is asking a UI elemt to inform the Model directly. Big bad no?
docsDir.addEventListener(Event.SELECT, copyFile);
}
private function copyFile(e:Event):void {
_sourceFile = File.applicationStorageDirectory.resolvePath(msgDB.db);
_copyToDirectory = e.target.resolvePath(msgDB.db);
if (_copyToDirectory.exists) {
// Passing this event through the Controller seems to create complexity,
// or at least unnecessary lines of code. Is there an advantage gained by
// communicating to the view through the controller here?
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.FILE_ALREADY_EXISTS);
dispatchEvent(evt);
}
else {
replaceFile();
}
}
public function replaceFile() : void {
var evt:CustomDataEvent = new CustomDataEvent(CustomDataEvent.COPY_COMPLETE);
try {
_sourceFile.copyTo(_copyToDirectory, true);
dispatchEvent(evt);
}
catch (error:Error) {
evt.param = error.message;
dispatchEvent(evt);
}
_sourceFile = null;
_copyToDirectory = null;
}
public function closeDBAndReplace() : void {
// The file cannot be deleted if there is a SQLConnection to it.
// The class that is aware of a possible connection also does the
// deletion. But deleting the file seems to conceptually
// fit into this class better
_data.addEventListener(CustomDataEvent.DRILL_RESET, findFile, false, 0,
true);
_data.deleteDBFile();
}
private function findFile(e:CustomDataEvent) : void {
_data.removeEventListener(CustomDataEvent.DRILL_RESET, findFile, false);
var docsDir:File = File.desktopDirectory;
docsDir.browseForOpen('Select msgDB.db file ...');
docsDir.addEventListener(Event.SELECT, replaceDBFile);
}
private function replaceDBFile(e:Event):void {
var sourceFile:File = e.target as File;
var destination:File =
File.applicationStorageDirectory.resolvePath(msgDB.db);
try {
sourceFile.copyTo(destination, true);
dispatchEvent(new CustomDataEvent(CustomDataEvent.RESTART_REQUIRED));
}
catch (error:Error) {
trace(Error:, error.message);
}
}
}
}
On 2/17/12 6:07 PM, Ross Sclafani ross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code in question and looking in the appropriate branch.
Does it store data? It's in the model.
Does it interpret and display data? Try your views
Re: [Flashcoders] MVC style Correction
Apparently there are no rules.
Just call it MVC and it's MVC I guess.
Ross P. Sclafani
Owner / Creative Director
Neuromantic Industries
http://www.neuromantic.com
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
347.204.5714
On Feb 24, 2012, at 10:15 AM, Merrill, Jason
jason.merr...@bankofamerica.com wrote:
Maybe I'm off, but I don't think the controller should manipulate data.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mattheis,
Erik (MIN-WSW)
Sent: Thursday, February 23, 2012 8:26 PM
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Ross Sclafani ross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code in question and looking in the appropriate branch.
Does it store data? It's in the model. Does it interpret and display data?
Try your views. Does it manipulate data? Look in the controller.
This thread has been useful, thanks all. I've a ton of questions regarding
judgment calls and below I post a class illustrating a few I've struggled
with. The comments are intended to be my questions/admissions of bafflement.
I'm unsure where in a MVC this class should go as its main purpose is to work
with the File class which itself has methods which retrieve
(File.applicationDirectory), interpret (File.exists) and display
(File.browseForOpen) data.
The class also is a dreaded example of allowing the view to listen directly
to the model for events, perhaps only because I've misguidedly decided to
make it part of the model as it has to do with copying and deleting a SQLite
file used in the app.
package mvc.model {
/* saveFileAs() saves a copy of a SQLite DB for the purposes of transferring
data to an instance of this app on another computer.
closeDBAndReplace() = replaces the db file if the user is importing data.
*/
import flash.events.EventDispatcher;
import flash.events.Event;
import flash.filesystem.File;
// class Data works with a SQLite DB
import mvc.model.Data;
// Where in a MVC should custom event classes // be located? I wish to pass
my own objects // along with events, usually Transfer Objects
// or a string to be displayed
import mvc.controller.CustomDataEvent;
public class ManipulateDBFile extends EventDispatcher {
private var _data:Data;
private var _sourceFile:File;
private var _copyToDirectory:File;
public function ManipulateDBFile(data:Data) {
_data = data;
}
public function saveFileAs() : void {
var docsDir:File = File.desktopDirectory;
// This creates a UI element. I would look for this code in the view!
docsDir.browseForDirectory('Save File in ...');
// This is asking a UI elemt to inform the Model directly. Big bad no?
docsDir.addEventListener(Event.SELECT, copyFile);
}
private function copyFile(e:Event):void {
_sourceFile = File.applicationStorageDirectory.resolvePath(msgDB.db);
_copyToDirectory = e.target.resolvePath(msgDB.db);
if (_copyToDirectory.exists) {
// Passing this event through the Controller seems to create complexity,
// or at least unnecessary lines of code. Is there an advantage gained by
// communicating to the view through the controller here?
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.FILE_ALREADY_EXISTS);
dispatchEvent(evt);
}
else {
replaceFile();
}
}
public function replaceFile() : void {
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.COPY_COMPLETE);
try {
_sourceFile.copyTo(_copyToDirectory, true);
dispatchEvent(evt);
}
catch (error:Error) {
evt.param = error.message;
dispatchEvent(evt);
}
_sourceFile = null;
_copyToDirectory = null;
}
public function closeDBAndReplace() : void {
// The file cannot be deleted if there is a SQLConnection to it.
// The class that is aware of a possible connection also does the
// deletion. But deleting the file seems to conceptually
// fit into this class better
_data.addEventListener(CustomDataEvent.DRILL_RESET, findFile, false, 0,
true);
_data.deleteDBFile();
}
private function findFile(e:CustomDataEvent) : void {
_data.removeEventListener(CustomDataEvent.DRILL_RESET, findFile, false);
var docsDir:File = File.desktopDirectory;
docsDir.browseForOpen('Select msgDB.db file ...');
docsDir.addEventListener(Event.SELECT, replaceDBFile);
}
private function replaceDBFile(e:Event):void {
var sourceFile:File = e.target as File;
var destination:File =
File.applicationStorageDirectory.resolvePath(msgDB.db);
try {
sourceFile.copyTo(destination, true);
dispatchEvent(new CustomDataEvent(CustomDataEvent.RESTART_REQUIRED
RE: [Flashcoders] MVC style Correction
No rules, you're right, just having the controller manipulate data just seems
to go against the spirit of what MVC is all about. Controllers are usually
used as communication busses in my experience.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ross Sclafani
Sent: Friday, February 24, 2012 4:29 PM
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Apparently there are no rules.
Just call it MVC and it's MVC I guess.
Ross P. Sclafani
Owner / Creative Director
Neuromantic Industries
http://www.neuromantic.com
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
347.204.5714
On Feb 24, 2012, at 10:15 AM, Merrill, Jason
jason.merr...@bankofamerica.com wrote:
Maybe I'm off, but I don't think the controller should manipulate data.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of
Mattheis, Erik (MIN-WSW)
Sent: Thursday, February 23, 2012 8:26 PM
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Ross Sclafani ross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code in question and looking in the appropriate branch.
Does it store data? It's in the model. Does it interpret and display data?
Try your views. Does it manipulate data? Look in the controller.
This thread has been useful, thanks all. I've a ton of questions regarding
judgment calls and below I post a class illustrating a few I've struggled
with. The comments are intended to be my questions/admissions of bafflement.
I'm unsure where in a MVC this class should go as its main purpose is to work
with the File class which itself has methods which retrieve
(File.applicationDirectory), interpret (File.exists) and display
(File.browseForOpen) data.
The class also is a dreaded example of allowing the view to listen directly
to the model for events, perhaps only because I've misguidedly decided to
make it part of the model as it has to do with copying and deleting a SQLite
file used in the app.
package mvc.model {
/* saveFileAs() saves a copy of a SQLite DB for the purposes of transferring
data to an instance of this app on another computer.
closeDBAndReplace() = replaces the db file if the user is importing data.
*/
import flash.events.EventDispatcher;
import flash.events.Event;
import flash.filesystem.File;
// class Data works with a SQLite DB
import mvc.model.Data;
// Where in a MVC should custom event classes // be located? I wish to pass
my own objects // along with events, usually Transfer Objects
// or a string to be displayed
import mvc.controller.CustomDataEvent;
public class ManipulateDBFile extends EventDispatcher {
private var _data:Data;
private var _sourceFile:File;
private var _copyToDirectory:File;
public function ManipulateDBFile(data:Data) {
_data = data;
}
public function saveFileAs() : void {
var docsDir:File = File.desktopDirectory;
// This creates a UI element. I would look for this code in the view!
docsDir.browseForDirectory('Save File in ...');
// This is asking a UI elemt to inform the Model directly. Big bad no?
docsDir.addEventListener(Event.SELECT, copyFile); }
private function copyFile(e:Event):void {
_sourceFile = File.applicationStorageDirectory.resolvePath(msgDB.db);
_copyToDirectory = e.target.resolvePath(msgDB.db);
if (_copyToDirectory.exists) {
// Passing this event through the Controller seems to create complexity,
// or at least unnecessary lines of code. Is there an advantage gained by
// communicating to the view through the controller here?
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.FILE_ALREADY_EXISTS);
dispatchEvent(evt);
}
else {
replaceFile();
}
}
public function replaceFile() : void {
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.COPY_COMPLETE);
try {
_sourceFile.copyTo(_copyToDirectory, true);
dispatchEvent(evt);
}
catch (error:Error) {
evt.param = error.message;
dispatchEvent(evt);
}
_sourceFile = null;
_copyToDirectory = null;
}
public function closeDBAndReplace() : void {
// The file cannot be deleted if there is a SQLConnection to it.
// The class that is aware of a possible connection also does the
// deletion. But deleting the file seems to conceptually
// fit into this class better
_data.addEventListener(CustomDataEvent.DRILL_RESET, findFile, false, 0,
true);
_data.deleteDBFile();
}
private
Re: [Flashcoders] MVC style Correction
Yeah I understand how different the flavors are now. I didnt invent the
triangular flow paradigm of my framework, I read it in a book.
Lots of books, lots of 'spirits'
In the end it's just another 3 letter acronym.
Ross P. Sclafani
Owner / Creative Director
Neuromantic Industries
http://www.neuromantic.com
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
347.204.5714
On Feb 24, 2012, at 4:45 PM, Merrill, Jason jason.merr...@bankofamerica.com
wrote:
No rules, you're right, just having the controller manipulate data just seems
to go against the spirit of what MVC is all about. Controllers are usually
used as communication busses in my experience.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ross Sclafani
Sent: Friday, February 24, 2012 4:29 PM
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Apparently there are no rules.
Just call it MVC and it's MVC I guess.
Ross P. Sclafani
Owner / Creative Director
Neuromantic Industries
http://www.neuromantic.com
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
347.204.5714
On Feb 24, 2012, at 10:15 AM, Merrill, Jason
jason.merr...@bankofamerica.com wrote:
Maybe I'm off, but I don't think the controller should manipulate data.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of
Mattheis, Erik (MIN-WSW)
Sent: Thursday, February 23, 2012 8:26 PM
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
Ross Sclafani ross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code in question and looking in the appropriate branch.
Does it store data? It's in the model. Does it interpret and display data?
Try your views. Does it manipulate data? Look in the controller.
This thread has been useful, thanks all. I've a ton of questions regarding
judgment calls and below I post a class illustrating a few I've struggled
with. The comments are intended to be my questions/admissions of bafflement.
I'm unsure where in a MVC this class should go as its main purpose is to
work with the File class which itself has methods which retrieve
(File.applicationDirectory), interpret (File.exists) and display
(File.browseForOpen) data.
The class also is a dreaded example of allowing the view to listen directly
to the model for events, perhaps only because I've misguidedly decided to
make it part of the model as it has to do with copying and deleting a SQLite
file used in the app.
package mvc.model {
/* saveFileAs() saves a copy of a SQLite DB for the purposes of
transferring data to an instance of this app on another computer.
closeDBAndReplace() = replaces the db file if the user is importing data.
*/
import flash.events.EventDispatcher;
import flash.events.Event;
import flash.filesystem.File;
// class Data works with a SQLite DB
import mvc.model.Data;
// Where in a MVC should custom event classes // be located? I wish to pass
my own objects // along with events, usually Transfer Objects
// or a string to be displayed
import mvc.controller.CustomDataEvent;
public class ManipulateDBFile extends EventDispatcher {
private var _data:Data;
private var _sourceFile:File;
private var _copyToDirectory:File;
public function ManipulateDBFile(data:Data) {
_data = data;
}
public function saveFileAs() : void {
var docsDir:File = File.desktopDirectory;
// This creates a UI element. I would look for this code in the view!
docsDir.browseForDirectory('Save File in ...');
// This is asking a UI elemt to inform the Model directly. Big bad no?
docsDir.addEventListener(Event.SELECT, copyFile); }
private function copyFile(e:Event):void {
_sourceFile = File.applicationStorageDirectory.resolvePath(msgDB.db);
_copyToDirectory = e.target.resolvePath(msgDB.db);
if (_copyToDirectory.exists) {
// Passing this event through the Controller seems to create complexity,
// or at least unnecessary lines of code. Is there an advantage gained by
// communicating to the view through the controller here?
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.FILE_ALREADY_EXISTS);
dispatchEvent(evt);
}
else {
replaceFile();
}
}
public function replaceFile() : void {
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.COPY_COMPLETE);
try {
_sourceFile.copyTo(_copyToDirectory, true);
dispatchEvent(evt);
}
catch (error:Error) {
evt.param = error.message
Re: [Flashcoders] MVC style Correction
Ross Sclafani ross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code in question and looking in the appropriate branch.
Does it store data? It's in the model. Does it interpret and display data? Try
your views. Does it manipulate data? Look in the controller.
This thread has been useful, thanks all. I've a ton of questions regarding
judgment calls and below I post a class illustrating a few I've struggled with.
The comments are intended to be my questions/admissions of bafflement. I'm
unsure where in a MVC this class should go as its main purpose is to work with
the File class which itself has methods which retrieve
(File.applicationDirectory), interpret (File.exists) and display
(File.browseForOpen) data.
The class also is a dreaded example of allowing the view to listen directly to
the model for events, perhaps only because I've misguidedly decided to make it
part of the model as it has to do with copying and deleting a SQLite file used
in the app.
package mvc.model {
/* saveFileAs() saves a copy of a SQLite DB for the purposes of
transferring data to an instance of this app on another
computer.
closeDBAndReplace() = replaces the db file if the user
is importing data.
*/
import flash.events.EventDispatcher;
import flash.events.Event;
import flash.filesystem.File;
// class Data works with a SQLite DB
import mvc.model.Data;
// Where in a MVC should custom event classes
// be located? I wish to pass my own objects
// along with events, usually Transfer Objects
// or a string to be displayed
import mvc.controller.CustomDataEvent;
public class ManipulateDBFile extends EventDispatcher {
private var _data:Data;
private var _sourceFile:File;
private var _copyToDirectory:File;
public function ManipulateDBFile(data:Data) {
_data = data;
}
public function saveFileAs() : void {
var docsDir:File = File.desktopDirectory;
// This creates a UI element. I would look for this code in the view!
docsDir.browseForDirectory('Save File in ...');
// This is asking a UI elemt to inform the Model directly. Big bad no?
docsDir.addEventListener(Event.SELECT, copyFile);
}
private function copyFile(e:Event):void {
_sourceFile = File.applicationStorageDirectory.resolvePath(msgDB.db);
_copyToDirectory = e.target.resolvePath(msgDB.db);
if (_copyToDirectory.exists) {
// Passing this event through the Controller seems to create complexity,
// or at least unnecessary lines of code. Is there an advantage gained by
// communicating to the view through the controller here?
var evt:CustomDataEvent = new
CustomDataEvent(CustomDataEvent.FILE_ALREADY_EXISTS);
dispatchEvent(evt);
}
else {
replaceFile();
}
}
public function replaceFile() : void {
var evt:CustomDataEvent = new CustomDataEvent(CustomDataEvent.COPY_COMPLETE);
try {
_sourceFile.copyTo(_copyToDirectory, true);
dispatchEvent(evt);
}
catch (error:Error) {
evt.param = error.message;
dispatchEvent(evt);
}
_sourceFile = null;
_copyToDirectory = null;
}
public function closeDBAndReplace() : void {
// The file cannot be deleted if there is a SQLConnection to it.
// The class that is aware of a possible connection also does the
// deletion. But deleting the file seems to conceptually
// fit into this class better
_data.addEventListener(CustomDataEvent.DRILL_RESET, findFile, false, 0,
true);
_data.deleteDBFile();
}
private function findFile(e:CustomDataEvent) : void {
_data.removeEventListener(CustomDataEvent.DRILL_RESET, findFile, false);
var docsDir:File = File.desktopDirectory;
docsDir.browseForOpen('Select msgDB.db file ...');
docsDir.addEventListener(Event.SELECT, replaceDBFile);
}
private function replaceDBFile(e:Event):void {
var sourceFile:File = e.target as File;
var destination:File =
File.applicationStorageDirectory.resolvePath(msgDB.db);
try {
sourceFile.copyTo(destination, true);
dispatchEvent(new CustomDataEvent(CustomDataEvent.RESTART_REQUIRED));
}
catch (error:Error) {
trace(Error:, error.message);
}
}
}
}
On 2/17/12 6:07 PM, Ross Sclafani ross.sclaf...@gmail.com wrote:
It is very easy to locate any code in one of my projects by ascertaining the
domain of the code in question and looking in the appropriate branch.
Does it store data? It's in the model.
Does it interpret and display data? Try your views.
Does it manipulate data? Look in the controller.
_ _ _
Erik Mattheis | Weber Shandwick
P: (952) 346.6610
M: (612) 377.2272
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
Kevin, Thanks for this and the video. I sure clears the theory. Best regards, Cor -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Kevin Newman Sent: zaterdag 18 februari 2012 6:10 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction That idea that the one thing MVC interpretations have in common - that models can only be updated by the controller makes sense. I tried to learn MVC a few times before it really stuck in my head. These where the problems I encountered: - What does MVC apply to? Is it an application level framework, or does it apply to tiny parts? In other words, do you have one or many in your app? (the scope the pattern was meant to apply to wasn't apparent from most descriptions.) - If I have to have a different view for each bit of model data - why bother with it all (the idea that you should work to make generic reusable views was never clear from most descriptions.) - How does the communication work again? Most diagrams are slightly different from the others and the dotted line connector lines vs. the solid lines never made as much sense as the road lines metaphor in the diagrams I linked to. The video I linked to addressed each of those issues, for the first time. Really though the problem is there are so many different interpretations of this pattern it's almost not really a pattern at all - more like a group of similar patterns, and that variance makes it hard to learn and understand (this thread is kind of proof, IMHO). What I ended up taking away from that video the first time I came accross it last year was the model - controller side, the idea that the controller directly manipuates the model and the views - it basically controls things. And the model broadcast tower diagrams for notifying the controller of changes was useful. I applied the same communication idea to the view side, as it seemed very iOS specific (even mimicking the UI of XCode to an extent in the diagrams), and overcomplicated anyway (3 different communication methods - enough already). I also don't usually bother with the data source or adapters (but I don't deal with a ton of changing remote data, usually just an item list that the view can handle). The guy in the video did slip a little assume the model and view don't communicate *for the purposes of this class* in there - which indicates at least at a some point having a model specific view makes sense (I do that a lot - frankly a lot of the UIs I make aren't generic, so why bother with a generic view framework). It's still mostly MVC in the end, but it's not a strict implementation of that specific pattern. But when someone is first trying to learn MVC, the exceptions could be superfluous information the learner probably doesn't need. Kevin N. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
Jord, This is exactly what I don't understand to do in actionscript! And that's why I think some example will visualize it to me. So I can analyze the flow of it all. Feel free to contact me offlist if you prefer. Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of jchilc...@interactivityunlimited.com Sent: donderdag 16 februari 2012 19:44 To: Flash Coders List Subject: RE: [Flashcoders] MVC style Correction Models shouldn't have any knowledge of each other or anything outside of themselves. The controller should usually be the first area to set up. Everything else is set up and managed by the controller (views, models, services). Usually, there will be one central controller that handles your main program management. Other controllers can be set up and delegated by the main controller, but this is not always necessary. In a well set up MVC application, Models and Views don't talk to each other. Rather, they let the controller carry out that communication. jord Original Message Subject: Re: [Flashcoders] MVC style Correction From: John McCormack j...@easypeasy.co.uk Date: Sat, February 18, 2012 1:22 pm To: Flash Coders List flashcoders@chattyfig.figleaf.com A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models, controller and Views find out about each other? Does everything register with the (single) controller? John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
maybe this will help: http://www.robotlegs.org/diagram/ the solid lines are method calls, the dashed lines are events On 17 February 2012 18:58, Cor c...@chello.nl wrote: Jord, This is exactly what I don't understand to do in actionscript! And that's why I think some example will visualize it to me. So I can analyze the flow of it all. Feel free to contact me offlist if you prefer. Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto: flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of jchilc...@interactivityunlimited.com Sent: donderdag 16 februari 2012 19:44 To: Flash Coders List Subject: RE: [Flashcoders] MVC style Correction Models shouldn't have any knowledge of each other or anything outside of themselves. The controller should usually be the first area to set up. Everything else is set up and managed by the controller (views, models, services). Usually, there will be one central controller that handles your main program management. Other controllers can be set up and delegated by the main controller, but this is not always necessary. In a well set up MVC application, Models and Views don't talk to each other. Rather, they let the controller carry out that communication. jord Original Message Subject: Re: [Flashcoders] MVC style Correction From: John McCormack j...@easypeasy.co.uk Date: Sat, February 18, 2012 1:22 pm To: Flash Coders List flashcoders@chattyfig.figleaf.com A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models, controller and Views find out about each other? Does everything register with the (single) controller? John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
Thank you! Another piece of the puzzle is filled in. Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ben Sand Sent: vrijdag 17 februari 2012 10:11 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction maybe this will help: http://www.robotlegs.org/diagram/ the solid lines are method calls, the dashed lines are events On 17 February 2012 18:58, Cor c...@chello.nl wrote: Jord, This is exactly what I don't understand to do in actionscript! And that's why I think some example will visualize it to me. So I can analyze the flow of it all. Feel free to contact me offlist if you prefer. Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto: flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of jchilc...@interactivityunlimited.com Sent: donderdag 16 februari 2012 19:44 To: Flash Coders List Subject: RE: [Flashcoders] MVC style Correction Models shouldn't have any knowledge of each other or anything outside of themselves. The controller should usually be the first area to set up. Everything else is set up and managed by the controller (views, models, services). Usually, there will be one central controller that handles your main program management. Other controllers can be set up and delegated by the main controller, but this is not always necessary. In a well set up MVC application, Models and Views don't talk to each other. Rather, they let the controller carry out that communication. jord Original Message Subject: Re: [Flashcoders] MVC style Correction From: John McCormack j...@easypeasy.co.uk Date: Sat, February 18, 2012 1:22 pm To: Flash Coders List flashcoders@chattyfig.figleaf.com A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models, controller and Views find out about each other? Does everything register with the (single) controller? John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
That is a great picture. Does a controller know an instance of a model? Orr does the model register with the controller as a subscriber for specific data changes or events? Most of all, I wonder how all the parts gets to know each other. John On 17/02/2012 09:11, Ben Sand wrote: maybe this will help: http://www.robotlegs.org/diagram/ the solid lines are method calls, the dashed lines are events On 17 February 2012 18:58, Corc...@chello.nl wrote: Jord, This is exactly what I don't understand to do in actionscript! And that's why I think some example will visualize it to me. So I can analyze the flow of it all. Feel free to contact me offlist if you prefer. Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto: flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of jchilc...@interactivityunlimited.com Sent: donderdag 16 februari 2012 19:44 To: Flash Coders List Subject: RE: [Flashcoders] MVC style Correction Models shouldn't have any knowledge of each other or anything outside of themselves. The controller should usually be the first area to set up. Everything else is set up and managed by the controller (views, models, services). Usually, there will be one central controller that handles your main program management. Other controllers can be set up and delegated by the main controller, but this is not always necessary. In a well set up MVC application, Models and Views don't talk to each other. Rather, they let the controller carry out that communication. jord Original Message Subject: Re: [Flashcoders] MVC style Correction From: John McCormackj...@easypeasy.co.uk Date: Sat, February 18, 2012 1:22 pm To: Flash Coders Listflashcoders@chattyfig.figleaf.com A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models, controller and Views find out about each other? Does everything register with the (single) controller? John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
This is particular to RobotLegs. RobotLegs links a lot of the components in the Context* and then handles dependency injection. Other MVC frameworks may have different approaches, here's a good comparison of Flash MVC frameworks: http://www.slideshare.net/RichardLord/application-frameworks-the-good-the-bad-the-ugly *In RobotLegs there is also the possibility to setup a different type of Context that uses Signals instead of Events for some communication. This provides greater type safety, but because signals can't replace all events it leaves you with two systems to manage, so we ultimately decided against it. On 20 February 2012 08:17, John McCormack j...@easypeasy.co.uk wrote: That is a great picture. Does a controller know an instance of a model? Orr does the model register with the controller as a subscriber for specific data changes or events? Most of all, I wonder how all the parts gets to know each other. John On 17/02/2012 09:11, Ben Sand wrote: maybe this will help: http://www.robotlegs.org/**diagram/ http://www.robotlegs.org/diagram/ the solid lines are method calls, the dashed lines are events On 17 February 2012 18:58, Corc...@chello.nl wrote: Jord, This is exactly what I don't understand to do in actionscript! And that's why I think some example will visualize it to me. So I can analyze the flow of it all. Feel free to contact me offlist if you prefer. Best regards, Cor van Dooren -Original Message- From: flashcoders-bounces@chattyfig.**figleaf.comflashcoders-boun...@chattyfig.figleaf.com[mailto: flashcoders-bounces@chattyfig.**figleaf.comflashcoders-boun...@chattyfig.figleaf.com] On Behalf Of jchilcott@**interactivityunlimited.comjchilc...@interactivityunlimited.com Sent: donderdag 16 februari 2012 19:44 To: Flash Coders List Subject: RE: [Flashcoders] MVC style Correction Models shouldn't have any knowledge of each other or anything outside of themselves. The controller should usually be the first area to set up. Everything else is set up and managed by the controller (views, models, services). Usually, there will be one central controller that handles your main program management. Other controllers can be set up and delegated by the main controller, but this is not always necessary. In a well set up MVC application, Models and Views don't talk to each other. Rather, they let the controller carry out that communication. jord Original Message Subject: Re: [Flashcoders] MVC style Correction From: John McCormackj...@easypeasy.co.uk** Date: Sat, February 18, 2012 1:22 pm To: Flash Coders Listflashcoders@chattyfig.**figleaf.comflashcoders@chattyfig.figleaf.com A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models, controller and Views find out about each other? Does everything register with the (single) controller? John __**_ Flashcoders mailing list Flashcoders@chattyfig.figleaf.**com Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/**mailman/listinfo/flashcodershttp://chattyfig.figleaf.com/mailman/listinfo/flashcoders __**_ Flashcoders mailing list Flashcoders@chattyfig.figleaf.**com Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/**mailman/listinfo/flashcodershttp://chattyfig.figleaf.com/mailman/listinfo/flashcoders __**_ Flashcoders mailing list Flashcoders@chattyfig.figleaf.**com Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/**mailman/listinfo/flashcodershttp://chattyfig.figleaf.com/mailman/listinfo/flashcoders __**_ Flashcoders mailing list Flashcoders@chattyfig.figleaf.**com Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/**mailman/listinfo/flashcodershttp://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Hands down the best explanation of MVC I've ever seen anywhere, is in this iTunes U series (item 43 at the bottom of the list) - you can just grab the slides too, but you'll miss all the emotion and humor of the delivery :-) http://itunes.apple.com/us/itunes-u/ipad-iphone-application-development/id473757255 There seems to be some basic pieces that are commonly missing from most descriptions of MVC: - Models have model data, broadcast changes to listening controllers, are updated directly by the controller. - Views have view data, data that is specific to the view, are updated directly by the controller, broadcast changes to listening controllers. - Models shouldn't communicate with Views (ever). - Views shouldn't communicate with Models (ever). A lot of examples of MVC I've seen take a shortcut and basically send the model data to a view which renders that data, but that isn't MVC at all. Kevin N. On 2/16/12 1:43 PM, jchilc...@interactivityunlimited.com wrote: Models and Views don't talk to each other. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I just rewatched the video, and it turns out that I forgot about the more complicated version with data sources. But still, if I got it right, the general idea is the controller adjusts the data into the generic formats for generic views (either all at once if you skip the data source glue, or through an adapter), it doesn't just pass along the model's raw data. Kevin N. On 2/17/12 5:18 PM, Kevin Newman wrote: - Views have view data, data that is specific to the view, are updated directly by the controller, broadcast changes to listening controllers. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
Can somebody show me a View class that doesn't update itself? What does it do? Are all of its properties public? Conversely, can someone show me a controller class that does the work of both modifying the model and manipulating the view? Does it lead to a ton of code in one class? I'm not suggesting my version of MVC is the only correct one, and while I'm not a fan of controller-centric mvc (like cocoa) i understand there are successful implementations (like iOS) That said, I have never been shown an MVC implementation in which anything is allowed to alter the model other than the controller, it's my current understanding that that's the only fundamental requirement of MVC no matter what flavor. Further, I can attest to the fact that my approach has a real advantage in keeping display, state, and business logic highly discrete and evenly distributed code wise. It is very easy to locate any code in one of my projects by ascertaining the domain of the code in question and looking in the appropriate branch. Does it store data? It's in the model. Does it interpret and display data? Try your views. Does it manipulate data? Look in the controller. Easy as MVC. This separation of interests is what appeals to me about the pattern, and I've had great success not only creating apps with my particular approach, but I've also been able to pick them back after any amount of time and track down the code behind any feature very quickly. If anyone doesn't mind detailing the benefits of another approach as I did mine, I'd love to disrupt these dogmatic feelings I'm having. I don't need to be told I'm wrong, because clearly I'm not. I don't need more opinions about what 'correct' MVC looks like because my system works extremely well. Im asking for concrete examples of different takes on MVC and what makes them advantageous. There has to be something left to learn on the matter.. I'll let you know when I get my framework up on the hub. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 17, 2012, at 5:18 PM, Kevin Newman capta...@unfocus.com wrote: Hands down the best explanation of MVC I've ever seen anywhere, is in this iTunes U series (item 43 at the bottom of the list) - you can just grab the slides too, but you'll miss all the emotion and humor of the delivery :-) http://itunes.apple.com/us/itunes-u/ipad-iphone-application-development/id473757255 There seems to be some basic pieces that are commonly missing from most descriptions of MVC: - Models have model data, broadcast changes to listening controllers, are updated directly by the controller. - Views have view data, data that is specific to the view, are updated directly by the controller, broadcast changes to listening controllers. - Models shouldn't communicate with Views (ever). - Views shouldn't communicate with Models (ever). A lot of examples of MVC I've seen take a shortcut and basically send the model data to a view which renders that data, but that isn't MVC at all. Kevin N. On 2/16/12 1:43 PM, jchilc...@interactivityunlimited.com wrote: Models and Views don't talk to each other. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
That idea that the one thing MVC interpretations have in common - that models can only be updated by the controller makes sense. I tried to learn MVC a few times before it really stuck in my head. These where the problems I encountered: - What does MVC apply to? Is it an application level framework, or does it apply to tiny parts? In other words, do you have one or many in your app? (the scope the pattern was meant to apply to wasn't apparent from most descriptions.) - If I have to have a different view for each bit of model data - why bother with it all (the idea that you should work to make generic reusable views was never clear from most descriptions.) - How does the communication work again? Most diagrams are slightly different from the others and the dotted line connector lines vs. the solid lines never made as much sense as the road lines metaphor in the diagrams I linked to. The video I linked to addressed each of those issues, for the first time. Really though the problem is there are so many different interpretations of this pattern it's almost not really a pattern at all - more like a group of similar patterns, and that variance makes it hard to learn and understand (this thread is kind of proof, IMHO). What I ended up taking away from that video the first time I came accross it last year was the model - controller side, the idea that the controller directly manipuates the model and the views - it basically controls things. And the model broadcast tower diagrams for notifying the controller of changes was useful. I applied the same communication idea to the view side, as it seemed very iOS specific (even mimicking the UI of XCode to an extent in the diagrams), and overcomplicated anyway (3 different communication methods - enough already). I also don't usually bother with the data source or adapters (but I don't deal with a ton of changing remote data, usually just an item list that the view can handle). The guy in the video did slip a little assume the model and view don't communicate *for the purposes of this class* in there - which indicates at least at a some point having a model specific view makes sense (I do that a lot - frankly a lot of the UIs I make aren't generic, so why bother with a generic view framework). It's still mostly MVC in the end, but it's not a strict implementation of that specific pattern. But when someone is first trying to learn MVC, the exceptions could be superfluous information the learner probably doesn't need. Kevin N. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style
Ross, that has to be the best explanation of MVC I've ever read. Combined with your example, I finally *really* understand the concepts. Thank you! Bryan Thompson -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ross Sclafani Sent: Wednesday, February 15, 2012 4:05 PM To: Flash Coders List Cc: Flash Coders List Subject: Re: [Flashcoders] MVC style I am an MVC purist, I always proceed as follows: Models should ONLY store information, particularly the state of the application and any data retrieved from disk or the network. Views hold a reference to a model, watch it for updates, and respond to those updates by rendering the model in its current state. 'rendering' could refer to manipulating the display list in flash, outputting some text to stout (or trace) serving up some JSON from a server app, whatever way of expressing the state of the model your app requires. Views are also responsible for handling events that occur in their domain, and forwarding them to the appropriate Controllers. Controllers exist to manipulate models. The only acceptable way to alter a model is via a controller. Whether its storing data from a Web service in the model, or altering the state of the app in response to user interaction, the controllers hold all of the business logic that define how the app behaves. Ideally, in AS3, the models consist of no methods except accessors that retrieve values from private vars and store values there and notify subscribed views of the update. Event dispatcher is a fantastic base class for a model. Equally, wherever possible, a controller should only consist of methods. Properties are for the model. This sets up a unidirectional flow of interaction and display. The controller populates the model, the model notifies the views, the views change. The changed view incites some user interaction, the view tells the controller what the user wants to happen, and the controller alters the state of the model accordingly, which then notifies the views to change, and so on and so forth. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style
I agree!!! Thanks again, Ross!! Ross quoted: Now imagine a Model with more properties. And tons of different Views of them that data. Some of which provide a UI linked to Controller methods that manipulate it. -- end quote -- I would love to see a next level example of a multi-model -view-controller Best regards, Cor van Dooren -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Bryan Thompson Sent: donderdag 16 februari 2012 9:37 To: 'Flash Coders List' Subject: RE: [Flashcoders] MVC style Ross, that has to be the best explanation of MVC I've ever read. Combined with your example, I finally *really* understand the concepts. Thank you! Bryan Thompson -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ross Sclafani Sent: Wednesday, February 15, 2012 4:05 PM To: Flash Coders List Cc: Flash Coders List Subject: Re: [Flashcoders] MVC style I am an MVC purist, I always proceed as follows: Models should ONLY store information, particularly the state of the application and any data retrieved from disk or the network. Views hold a reference to a model, watch it for updates, and respond to those updates by rendering the model in its current state. 'rendering' could refer to manipulating the display list in flash, outputting some text to stout (or trace) serving up some JSON from a server app, whatever way of expressing the state of the model your app requires. Views are also responsible for handling events that occur in their domain, and forwarding them to the appropriate Controllers. Controllers exist to manipulate models. The only acceptable way to alter a model is via a controller. Whether its storing data from a Web service in the model, or altering the state of the app in response to user interaction, the controllers hold all of the business logic that define how the app behaves. Ideally, in AS3, the models consist of no methods except accessors that retrieve values from private vars and store values there and notify subscribed views of the update. Event dispatcher is a fantastic base class for a model. Equally, wherever possible, a controller should only consist of methods. Properties are for the model. This sets up a unidirectional flow of interaction and display. The controller populates the model, the model notifies the views, the views change. The changed view incites some user interaction, the view tells the controller what the user wants to happen, and the controller alters the state of the model accordingly, which then notifies the views to change, and so on and so forth. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style
+1 On Feb 16, 2012, at 2:36 AM, Bryan Thompson wrote: Ross, that has to be the best explanation of MVC I've ever read. Combined with your example, I finally *really* understand the concepts. Thank you! Bryan Thompson -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ross Sclafani Sent: Wednesday, February 15, 2012 4:05 PM To: Flash Coders List Cc: Flash Coders List Subject: Re: [Flashcoders] MVC style I am an MVC purist, I always proceed as follows: Models should ONLY store information, particularly the state of the application and any data retrieved from disk or the network. Views hold a reference to a model, watch it for updates, and respond to those updates by rendering the model in its current state. 'rendering' could refer to manipulating the display list in flash, outputting some text to stout (or trace) serving up some JSON from a server app, whatever way of expressing the state of the model your app requires. Views are also responsible for handling events that occur in their domain, and forwarding them to the appropriate Controllers. Controllers exist to manipulate models. The only acceptable way to alter a model is via a controller. Whether its storing data from a Web service in the model, or altering the state of the app in response to user interaction, the controllers hold all of the business logic that define how the app behaves. Ideally, in AS3, the models consist of no methods except accessors that retrieve values from private vars and store values there and notify subscribed views of the update. Event dispatcher is a fantastic base class for a model. Equally, wherever possible, a controller should only consist of methods. Properties are for the model. This sets up a unidirectional flow of interaction and display. The controller populates the model, the model notifies the views, the views change. The changed view incites some user interaction, the view tells the controller what the user wants to happen, and the controller alters the state of the model accordingly, which then notifies the views to change, and so on and so forth. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style
We work with two MVC frameworks: RobotLegs in Flash and RubyonRails on the server. RubyonRails mandates a thin controller fat model paradigm and we try to user that in Flash as well. Under this paradigm, wherever possible, things should be in the model. One good reason for doing this is code reuse. The last thing you want to be doing is putting the same thing in multiple controllers. Where context matters, things need to be in the controller, but I usually then have them call controller methods. There are different ways of thinking about this, but this is how rails mandates it and the pattern we follow. No matter what MVC paradigm you follow, I think everyone would agree the model is responsible for ensuring data integrity. Any validations etc. should be in the model as part of the setter methods to ensure only compliant data ever makes into your value objects / database. When it comes to permissions we handle them at a controller level, but they are centralised in a utility configuration. The system we use allows for model based permissions as well but we find these are too limited as context matters for permissions and it's hard to deal with this meaningfully in the model. On 16 February 2012 05:32, David Hunter m...@davidhunterdesign.com wrote: Hello list, If I am making an application with MVC pattern and calculations are needed to be performed on the data when the user interacts with the application, would you: do the calculations in the Model? create a separate class that handles the calculations and puts the results in the model? do the calculations in the Controller? looking forward to hearing people's thoughts on this, david -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style
yeah, getting more into robotlegs took me away from fat controllers, the single are a really nice way to make sure you don't end up with any monolithic classes. if your calculations change the data i'd say they should be in the model and exposed through it's API. if they are just using the data from the model then no. On 16 February 2012 11:27, Ben Sand b...@bensand.com wrote: We work with two MVC frameworks: RobotLegs in Flash and RubyonRails on the server. RubyonRails mandates a thin controller fat model paradigm and we try to user that in Flash as well. Under this paradigm, wherever possible, things should be in the model. One good reason for doing this is code reuse. The last thing you want to be doing is putting the same thing in multiple controllers. Where context matters, things need to be in the controller, but I usually then have them call controller methods. There are different ways of thinking about this, but this is how rails mandates it and the pattern we follow. No matter what MVC paradigm you follow, I think everyone would agree the model is responsible for ensuring data integrity. Any validations etc. should be in the model as part of the setter methods to ensure only compliant data ever makes into your value objects / database. When it comes to permissions we handle them at a controller level, but they are centralised in a utility configuration. The system we use allows for model based permissions as well but we find these are too limited as context matters for permissions and it's hard to deal with this meaningfully in the model. On 16 February 2012 05:32, David Hunter m...@davidhunterdesign.com wrote: Hello list, If I am making an application with MVC pattern and calculations are needed to be performed on the data when the user interacts with the application, would you: do the calculations in the Model? create a separate class that handles the calculations and puts the results in the model? do the calculations in the Controller? looking forward to hearing people's thoughts on this, david -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style
A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models find out about each other? John On 16/02/2012 00:05, Ross Sclafani wrote: I am an MVC purist, I always proceed as follows: Models should ONLY store information, particularly the state of the application and any data retrieved from disk or the network. Views hold a reference to a model, watch it for updates, and respond to those updates by rendering the model in its current state. 'rendering' could refer to manipulating the display list in flash, outputting some text to stout (or trace) serving up some JSON from a server app, whatever way of expressing the state of the model your app requires. Views are also responsible for handling events that occur in their domain, and forwarding them to the appropriate Controllers. Controllers exist to manipulate models. The only acceptable way to alter a model is via a controller. Whether its storing data from a Web service in the model, or altering the state of the app in response to user interaction, the controllers hold all of the business logic that define how the app behaves. Ideally, in AS3, the models consist of no methods except accessors that retrieve values from private vars and store values there and notify subscribed views of the update. Event dispatcher is a fantastic base class for a model. Equally, wherever possible, a controller should only consist of methods. Properties are for the model. This sets up a unidirectional flow of interaction and display. The controller populates the model, the model notifies the views, the views change. The changed view incites some user interaction, the view tells the controller what the user wants to happen, and the controller alters the state of the model accordingly, which then notifies the views to change, and so on and so forth. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 15, 2012, at 1:46 PM, Merrill, Jasonjason.merr...@bankofamerica.com wrote: Calculations would not be in the controller, they would be in the Model. Sometimes you can justify them being in the view if it's related to the view. Calculations are also in a Service class if they are part of a service in some way. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of David Hunter Sent: Wednesday, February 15, 2012 1:32 PM To: Flash Coders List Subject: [Flashcoders] MVC style Hello list, If I am making an application with MVC pattern and calculations are needed to be performed on the data when the user interacts with the application, would you: do the calculations in the Model? create a separate class that handles the calculations and puts the results in the model? do the calculations in the Controller? looking forward to hearing people's thoughts on this, david -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not
Re: [Flashcoders] MVC style Correction
A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models, controller and Views find out about each other? Does everything register with the (single) controller? John On 16/02/2012 00:05, Ross Sclafani wrote: I am an MVC purist, I always proceed as follows: Models should ONLY store information, particularly the state of the application and any data retrieved from disk or the network. Views hold a reference to a model, watch it for updates, and respond to those updates by rendering the model in its current state. 'rendering' could refer to manipulating the display list in flash, outputting some text to stout (or trace) serving up some JSON from a server app, whatever way of expressing the state of the model your app requires. Views are also responsible for handling events that occur in their domain, and forwarding them to the appropriate Controllers. Controllers exist to manipulate models. The only acceptable way to alter a model is via a controller. Whether its storing data from a Web service in the model, or altering the state of the app in response to user interaction, the controllers hold all of the business logic that define how the app behaves. Ideally, in AS3, the models consist of no methods except accessors that retrieve values from private vars and store values there and notify subscribed views of the update. Event dispatcher is a fantastic base class for a model. Equally, wherever possible, a controller should only consist of methods. Properties are for the model. This sets up a unidirectional flow of interaction and display. The controller populates the model, the model notifies the views, the views change. The changed view incites some user interaction, the view tells the controller what the user wants to happen, and the controller alters the state of the model accordingly, which then notifies the views to change, and so on and so forth. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 15, 2012, at 1:46 PM, Merrill, Jasonjason.merr...@bankofamerica.com wrote: Calculations would not be in the controller, they would be in the Model. Sometimes you can justify them being in the view if it's related to the view. Calculations are also in a Service class if they are part of a service in some way. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of David Hunter Sent: Wednesday, February 15, 2012 1:32 PM To: Flash Coders List Subject: [Flashcoders] MVC style Hello list, If I am making an application with MVC pattern and calculations are needed to be performed on the data when the user interacts with the application, would you: do the calculations in the Model? create a separate class that handles the calculations and puts the results in the model? do the calculations in the Controller? looking forward to hearing people's thoughts on this, david -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank
Re: [Flashcoders] MVC style
Yeah it hasn't been open source but I'm ready to do that soon. I'm having trouble parsing your other question, can you rephrase re: models knowing about each other? Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 18, 2012, at 1:19 PM, John McCormack j...@easypeasy.co.uk wrote: A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models find out about each other? John On 16/02/2012 00:05, Ross Sclafani wrote: I am an MVC purist, I always proceed as follows: Models should ONLY store information, particularly the state of the application and any data retrieved from disk or the network. Views hold a reference to a model, watch it for updates, and respond to those updates by rendering the model in its current state. 'rendering' could refer to manipulating the display list in flash, outputting some text to stout (or trace) serving up some JSON from a server app, whatever way of expressing the state of the model your app requires. Views are also responsible for handling events that occur in their domain, and forwarding them to the appropriate Controllers. Controllers exist to manipulate models. The only acceptable way to alter a model is via a controller. Whether its storing data from a Web service in the model, or altering the state of the app in response to user interaction, the controllers hold all of the business logic that define how the app behaves. Ideally, in AS3, the models consist of no methods except accessors that retrieve values from private vars and store values there and notify subscribed views of the update. Event dispatcher is a fantastic base class for a model. Equally, wherever possible, a controller should only consist of methods. Properties are for the model. This sets up a unidirectional flow of interaction and display. The controller populates the model, the model notifies the views, the views change. The changed view incites some user interaction, the view tells the controller what the user wants to happen, and the controller alters the state of the model accordingly, which then notifies the views to change, and so on and so forth. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 15, 2012, at 1:46 PM, Merrill, Jasonjason.merr...@bankofamerica.com wrote: Calculations would not be in the controller, they would be in the Model. Sometimes you can justify them being in the view if it's related to the view. Calculations are also in a Service class if they are part of a service in some way. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of David Hunter Sent: Wednesday, February 15, 2012 1:32 PM To: Flash Coders List Subject: [Flashcoders] MVC style Hello list, If I am making an application with MVC pattern and calculations are needed to be performed on the data when the user interacts with the application, would you: do the calculations in the Model? create a separate class that handles the calculations and puts the results in the model? do the calculations in the Controller? looking forward to hearing people's thoughts on this, david -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each
RE: [Flashcoders] MVC style Correction
Models shouldn't have any knowledge of each other or anything outside of themselves. The controller should usually be the first area to set up. Everything else is set up and managed by the controller (views, models, services). Usually, there will be one central controller that handles your main program management. Other controllers can be set up and delegated by the main controller, but this is not always necessary. In a well set up MVC application, Models and Views don't talk to each other. Rather, they let the controller carry out that communication. jord Original Message Subject: Re: [Flashcoders] MVC style Correction From: John McCormack j...@easypeasy.co.uk Date: Sat, February 18, 2012 1:22 pm To: Flash Coders List flashcoders@chattyfig.figleaf.com A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models, controller and Views find out about each other? Does everything register with the (single) controller? John ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style
Not really relevant to the thread, but I saw your CodeJS project Ross, you should take a look at my solution to Classical Inheritance in JavaScript; https://github.com/gigafied/minion Comes with dependency management and a build tool for building out different classes (and their dependencies) into separate minified JS files. On Thu, Feb 16, 2012 at 10:32 AM, Ross Sclafani ross.sclaf...@gmail.comwrote: Yeah it hasn't been open source but I'm ready to do that soon. I'm having trouble parsing your other question, can you rephrase re: models knowing about each other? Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 18, 2012, at 1:19 PM, John McCormack j...@easypeasy.co.uk wrote: A really nice explanation. I tried to find your EastAsMVC after being on your site, is it on the way? Also, what comes first, ie. how do the models find out about each other? John On 16/02/2012 00:05, Ross Sclafani wrote: I am an MVC purist, I always proceed as follows: Models should ONLY store information, particularly the state of the application and any data retrieved from disk or the network. Views hold a reference to a model, watch it for updates, and respond to those updates by rendering the model in its current state. 'rendering' could refer to manipulating the display list in flash, outputting some text to stout (or trace) serving up some JSON from a server app, whatever way of expressing the state of the model your app requires. Views are also responsible for handling events that occur in their domain, and forwarding them to the appropriate Controllers. Controllers exist to manipulate models. The only acceptable way to alter a model is via a controller. Whether its storing data from a Web service in the model, or altering the state of the app in response to user interaction, the controllers hold all of the business logic that define how the app behaves. Ideally, in AS3, the models consist of no methods except accessors that retrieve values from private vars and store values there and notify subscribed views of the update. Event dispatcher is a fantastic base class for a model. Equally, wherever possible, a controller should only consist of methods. Properties are for the model. This sets up a unidirectional flow of interaction and display. The controller populates the model, the model notifies the views, the views change. The changed view incites some user interaction, the view tells the controller what the user wants to happen, and the controller alters the state of the model accordingly, which then notifies the views to change, and so on and so forth. Ross P. Sclafani Owner / Creative Director Neuromantic Industries http://www.neuromantic.com http://ross.sclafani.net http://www.twitter.com/rosssclafani 347.204.5714 On Feb 15, 2012, at 1:46 PM, Merrill, Jason jason.merr...@bankofamerica.com wrote: Calculations would not be in the controller, they would be in the Model. Sometimes you can justify them being in the view if it's related to the view. Calculations are also in a Service class if they are part of a service in some way. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto: flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of David Hunter Sent: Wednesday, February 15, 2012 1:32 PM To: Flash Coders List Subject: [Flashcoders] MVC style Hello list, If I am making an application with MVC pattern and calculations are needed to be performed on the data when the user interacts with the application, would you: do the calculations in the Model? create a separate class that handles the calculations and puts the results in the model? do the calculations in the Controller? looking forward to hearing people's thoughts on this, david -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a
RE: [Flashcoders] MVC style
Calculations would not be in the controller, they would be in the Model. Sometimes you can justify them being in the view if it's related to the view. Calculations are also in a Service class if they are part of a service in some way. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of David Hunter Sent: Wednesday, February 15, 2012 1:32 PM To: Flash Coders List Subject: [Flashcoders] MVC style Hello list, If I am making an application with MVC pattern and calculations are needed to be performed on the data when the user interacts with the application, would you: do the calculations in the Model? create a separate class that handles the calculations and puts the results in the model? do the calculations in the Controller? looking forward to hearing people's thoughts on this, david -- David Hunter www.davidhunterdesign.com +44 (0) 7869 104 906 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
