i would recommend the o'reilly design patterns book - it gives a very simple mvc triad and then expands it with other patterns (like using the composite pattern for nesting views)
i did find a video that did a good job of explaining a quick mvc triad but it didn't go into detail about why it is set up that way and i can't find it right now hope this helps a On Tue, Jan 19, 2010 at 6:48 PM, Cor <c...@chello.nl> wrote: > Hi Jason, > > I hope you don't mind me addressing you of list. > If you do, please ignore this message and I apologize to you! > > I am trying to grasp the MVC pattern, but it is very hard for me. > I am looking for a very simple example which explains the way it works. > If you can help me with this, I would be very greatful. > > Thanks in advance. > Kind regards > Cor van Dooren > The Netherlands > > > -----Original Message----- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, > Jason > Sent: dinsdag 19 januari 2010 17:35 > To: Flash Coders List > Subject: RE: [Flashcoders] Using MVC for a site framework > > This is my opinion, I'm sure others will have their own that may differ > (and probably recommend you check out some frameworks - though that can > be a lot to tackle) : the controller would listen to the model to know > when the data is ready and available. It would then tell the view to > start building. The main class would hold the references to the model, > view, controller, but would not command any classes to do anything > really. You could have the view listen to the model as well and skip > the controller doing it, but I like the view to be more decoupled than > that. I usually try and keep most listeners in the controller where > possible, though many end up in the view, depending on the situation. I > never have listeners in the model though, only events that are > dispatched. > > I actually have the model start and do it's own XML loading, but you > could have the controller tell it to do that, just seems like an > unnecessary step. > > Another thing I do is have a main class called MVC that extends Sprite > or DisplayObject which initializes the model, view, controller, in > order, dispatches an event when all three are initialized, and provides > access to each via a singleton implementation. It allows me to access > any part of a model, view, controller from any other part just by > calling MVC.instance. Then it's just var _mvc:MVC = MVC.instancel; then > _mvc.model.myprop or _mvc.view.update() or whatever. That class looks > like this: > > package mvc > { > import events.MVCEvent; > import events.view.ViewEvent; > import events.controller.ControllerEvent; > import events.model.ModelEvent; > import mvc.controller.Controller; > import mvc.model.Model; > import mvc.view.View; > import flash.display.Sprite; > /** > * ... > * @author Jason Merrill - Bank of America > */ > public class MVC extends Sprite > { > public var view:View; > public var model:Model; > public var controller:Controller; > > private static var _instance:MVC; > > public function MVC() > { > if ( _instance != null ) > { > throw new Error( "Only one MVC instance should be > instantiated. Use MVC.instance instead." ); > } > else > { > _instance = this; > } > } > > public function initialize():void > { > model = new Model(); > view = new View(); > controller = new Controller(); > > model.addEventListener(ModelEvent.INITIALIZED, > onModelInitialized); > > controller.addEventListener(ControllerEvent.INITIALIZED, > onControllerInitialized); > view.addEventListener(ViewEvent.INITIALIZED, > onViewInitialized); > > model.initialize(); > } > > private function > onModelInitialized(event:ModelEvent):void > { > > model.removeEventListener(ModelEvent.INITIALIZED, onModelInitialized); > view.initialize(); > } > > private function onViewInitialized(event:ViewEvent):void > { > addChild(view); > view.removeEventListener(ViewEvent.INITIALIZED, > onViewInitialized); > controller.initialize(); > } > > private function > onControllerInitialized(event:ControllerEvent):void > { > > controller.removeEventListener(ControllerEvent.INITIALIZED, > onControllerInitialized); > dispatchEvent(new > MVCEvent(MVCEvent.INITIALIZED)); > } > > public static function get instance():MVC > { > if ( _instance == null ) > { > throw new Error( "MVC singleton instance not created > yet." ); > } > return _instance; > } > } > > } > > > Jason Merrill > > Bank of America Global Learning > Learning & Performance Soluions > > Join the Bank of America Flash Platform Community and visit our > Instructional Technology Design Blog > (note: these are for Bank of America employees only) > > > > > > -----Original Message----- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of allandt > bik-elliott (thefieldcomic.com) > Sent: Tuesday, January 19, 2010 11:09 AM > To: Flash Coders List > Subject: [Flashcoders] Using MVC for a site framework > > Hi guys > > I'm currently feeling my way through the o'reilly design patterns book > and > am going through the mvc design pattern as a way of dealing with > (micro)site > structures - dealing with opening and closing pages, loading data etc > but i > have a couple of questions that you guys will probably be able to > answer... > > i have a config xml file that points to the data xml, site css and > fonts.swf. I take it that the controller should have the responsibility > of > loading those files and storing the results in the model. However if i > include the site structure in the data xml as i would usually do, which > part > of the triad should be instantiating the views to create the pages? The > book > is set up that the Main.as class would be instantiating the views and > creating the site structure but that doesn't fit if the controller is > loading the xml files into the model. > > I would guess that the controller would trawl the xml and instantiate > the > page views and add them to the model but i'm not 100% on this > > I'd really appreciate your time on this matter as I'd like to build a > set of > classes that work with more than one project > > thanks > a > _______________________________________________ > 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 > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.730 / Virus Database: 270.14.149/2631 - Release Date: 01/18/10 > 17:56:00 > > _______________________________________________ > 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
