date:20120217

Re: [Flashcoders] MVC style Correction

2012-02-17 Thread Kevin Newman

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 Correction

2012-02-17 Thread Ross Sclafani

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

2012-02-17 Thread Kevin Newman

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

2012-02-17 Thread Kevin Newman

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

2012-02-17 Thread Ben Sand

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  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/ 
>>
>> the solid lines are method calls, the dashed lines are events
>>
>> On 17 February 2012 18:58, Cor  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.com[mailto:
>>> flashcoders-bounces@chattyfig.**figleaf.com]
>>> On Behalf Of
>>> jchilcott@**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
>>> Date: Sat, February 18, 2012 1:22 pm
>>> To: Flash Coders 
>>> List
>>> >
>>>
>>> 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
>
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] MVC style Correction

2012-02-17 Thread John McCormack


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, Cor  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
Date: Sat, February 18, 2012 1:22 pm
To: Flash Coders List

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] Fwd: MVC

2012-02-17 Thread Ross Sclafani

I'm firmly against views treating models as anything but read only.

Personal preference 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 17, 2012, at 1:11 PM, "Peter Ginneberge"  wrote:

> 
>> Main problem that I see with the code that was posted is that it breaks
>> a major MVC rule and teaches a real bad habit: Views shouldn't have any
>> knowledge of Models
> 
> Not sure where you get the idea that a View shouldn't communictate with the 
> Model directly:
> 
> This states otherwise: 
> http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
> 
> 
> Unlike the model, which may be loosely connected to multiple MVC triads, Each 
> view is associated with a unique controller and vice versa. Instance 
> variables in each maintain this tight coupling. A view's instance variable 
> controller points at its controller, and a controller's instance variable 
> view points at its associated view. And, because both must communicate with 
> their model, each has an instance variable model which points to the model 
> object. So, although the model is limited to sending self changed:, both the 
> view and the controller can send messages directly to each other and to their 
> model.
> 
> 
> For those wondering why I quote the above article:
> http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller#History
> 
> regards,
> Muzak
> 
> 
> - Original Message - From: 
> To: "Flash Coders List" 
> Sent: Thursday, February 16, 2012 3:07 PM
> Subject: RE: [Flashcoders] Fwd: MVC
> 
> 
>> Main problem that I see with the code that was posted is that it breaks
>> a major MVC rule and teaches a real bad habit: Views shouldn't have any
>> knowledge of Models and Models shouldn't care who's using them
>> (Controllers are just conduits between Views and Models). On a larger
>> scale, this would present itself to be a huge maintenance nightmare and
>> dependencies have now been created. Everything should be independent of
>> each other enough that I could replace one section without affecting the
>> operation of anything else in the application. In this case. the
>> controller should be passing either Value or Transfer Objects back and
>> forth between the View and Model. This way, I could change models on the
>> fly and the controller and view wouldn't suspect a thing.
>> 
>> RobotLegs is an excellent example for learning about MVC.
>> 
> 
> ___
> 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] Fwd: MVC

2012-02-17 Thread Peter Ginneberge




Main problem that I see with the code that was posted is that it breaks
a major MVC rule and teaches a real bad habit: Views shouldn't have any
knowledge of Models


Not sure where you get the idea that a View shouldn't communictate with the 
Model directly:

This states otherwise: 
http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html


Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice 
versa. Instance variables in each maintain this tight coupling. A view's instance variable controller points at its controller, and 
a controller's instance variable view points at its associated view. And, because both must communicate with their model, each has 
an instance variable model which points to the model object. So, although the model is limited to sending self changed:, both the 
view and the controller can send messages directly to each other and to their model.



For those wondering why I quote the above article:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller#History

regards,
Muzak


- Original Message - 
From: 

To: "Flash Coders List" 
Sent: Thursday, February 16, 2012 3:07 PM
Subject: RE: [Flashcoders] Fwd: MVC



Main problem that I see with the code that was posted is that it breaks
a major MVC rule and teaches a real bad habit: Views shouldn't have any
knowledge of Models and Models shouldn't care who's using them
(Controllers are just conduits between Views and Models). On a larger
scale, this would present itself to be a huge maintenance nightmare and
dependencies have now been created. Everything should be independent of
each other enough that I could replace one section without affecting the
operation of anything else in the application. In this case. the
controller should be passing either Value or Transfer Objects back and
forth between the View and Model. This way, I could change models on the
fly and the controller and view wouldn't suspect a thing.

RobotLegs is an excellent example for learning about MVC.



___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

RE: [Flashcoders] MVC style Correction

2012-02-17 Thread Cor

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  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 
> Date: Sat, February 18, 2012 1:22 pm
> To: Flash Coders List 
>
> 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] Sound control problem

2012-02-17 Thread Glen Pike


Hi,

I think you need to set the soundTransform of the MovieClip that 
contains the timeline sound?


Also look at the SoundMixer class for "global" controls - you may need 
the stopAll functionality when you add and remove MC's with sound 
to/from the stage.


Glen

On 16/02/2012 19:48, natalia Vikhtinskaya wrote:

Hi
I have mute button with class linked to this mc in the library

package lib
{
  import flash.display.*;
 import flash.events.*;
 import flash.utils.*;
import flash.media.*;

  public class MuteControl extends flash.display.MovieClip
 {
 private var _so:SoundTransform;
 public function MuteControl()
 {

_so=new SoundTransform();
_so.volume = 1;
soundTransform=_so;
this.addEventListener(MouseEvent.CLICK, 
muteControlButton);
this.buttonMode = true;
this.mouseChildren = false;
return;
 }



   private function muteControlButton(e:MouseEvent):void {
if (_so.volume==1){
_so.volume=0;
e.target.gotoAndStop(2);
} else {
_so.volume=1;
e.target.gotoAndStop(1);
}
this.soundTransform = _so;  //nothing changes
}



 }

}

muteControlButton function works correctly but sound does not change.
Sound file attached on Timeline. What is wrong?

Please advice.
___
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

2012-02-17 Thread Ben Sand

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  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 
> Date: Sat, February 18, 2012 1:22 pm
> To: Flash Coders List 
>
> 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

2012-02-17 Thread Cor

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 
Date: Sat, February 18, 2012 1:22 pm
To: Flash Coders List 

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

Re: [Flashcoders] MVC style Correction

Re: [Flashcoders] MVC style Correction

Re: [Flashcoders] MVC style Correction

Re: [Flashcoders] MVC style Correction

Re: [Flashcoders] MVC style Correction

Re: [Flashcoders] Fwd: MVC

Re: [Flashcoders] Fwd: MVC

RE: [Flashcoders] MVC style Correction

Re: [Flashcoders] Sound control problem

Re: [Flashcoders] MVC style Correction

RE: [Flashcoders] MVC style Correction

12 matches

Site Navigation

Mail list logo

Footer information