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
