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] Algorithm ideas
On 05/03/2012 23:12, Paul Andrews wrote: Lets imagine I have 100 sprites scattered around the stage - no regular pattern, but generally spread evenly. My task is to remove 40 of them. That's easy, but I want to remove them as evenly as possible, so the density thins but is reasonably consistent across the stage. Any ideas? I don't know if there is a standard algorithm for this. No worries - I worked it out. Should have had some thinking time before posting. Paul Paul ___ 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] Algorithm ideas
Lets imagine I have 100 sprites scattered around the stage - no regular pattern, but generally spread evenly. My task is to remove 40 of them. That's easy, but I want to remove them as evenly as possible, so the density thins but is reasonably consistent across the stage. Any ideas? I don't know if there is a standard algorithm for this. Paul ___ 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" To: "Flash Coders List" 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
>> 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
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
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
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
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" > To: > 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'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" To: 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
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" To: 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
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
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
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
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
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 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
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 in
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 >> represent
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
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
>>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/
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 ch
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
@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