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! >> 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 > > _______________________________________________ > 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
