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, 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
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
