RE: [Flashcoders] MVC style Correction
@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. :-) 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 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
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
RE: [Flashcoders] MVC style Correction
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
RE: [Flashcoders] MVC style Correction
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
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Monday, March 05, 2012 5:27 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] MVC style Correction
@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. :-)
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
Re: [Flashcoders] MVC style Correction
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,
Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
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
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Monday, March 05, 2012 5:27 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] MVC style Correction
@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. :-)
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
RE: [Flashcoders] MVC style Correction
It's the simplest form of MVC. I didn't say it was the best, I was just giving
the man what he asked for. :)
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews
Sent: Monday, March 05, 2012 9:11 AM
To: flashcoders@chattyfig.figleaf.com
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional views being
added or removed, requires that the controller be changed too. Any change to a
view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
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
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Monday, March 05, 2012 5:27 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] MVC style Correction
@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. :-)
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
Re: [Flashcoders] MVC style Correction
On 05/03/2012 14:13, Merrill, Jason wrote:
It's the simplest form of MVC. I didn't say it was the best, I was just giving
the man what he asked for. :)
Fair enough, but they do sell cigarettes with a health warning these
days.. ;-)
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews
Sent: Monday, March 05, 2012 9:11 AM
To: flashcoders@chattyfig.figleaf.com
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional views being
added or removed, requires that the controller be changed too. Any change to a
view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
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
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
Instructional Technology Architect II
Bank of America Global Learning
___
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Monday, March 05, 2012 5:27 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] MVC style Correction
@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. :-)
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
Re: [Flashcoders] MVC style Correction
i prefer to have the model update the views. preferably via event for loose coupling. the situations that a controller would alter a view in the versions of MVC i have studied are for things that are pure visual responses. like say a rollover: ROLL_OVER event on View -- calls onRollOver on controller -- sets highlight on View. Because the Flash SDK provides such a rich display API, I personally avoid this and leave any pure view event handling to the View internals to limit the public properties of Views. I could see a scenario where one such rollover needs to cause changes in multiple views, and this approach could be implemented, but i would normally rout these types updates through a submodel dedicated to UI. again, I value encapsulation above most other benefits of allowing the controller access to view properties, so i follow a standard unidirectional triangular flow. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC style Correction
OK, I almost started changing my approach, but this confirms I shouldn't. I stopped smoking in 1978 but I still listen to all the warnings. :-) Thank you!! -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ross Sclafani Sent: maandag 5 maart 2012 15:37 To: Flash Coders List Subject: Re: [Flashcoders] MVC style Correction i prefer to have the model update the views. preferably via event for loose coupling. the situations that a controller would alter a view in the versions of MVC i have studied are for things that are pure visual responses. like say a rollover: ROLL_OVER event on View -- calls onRollOver on controller -- sets highlight on View. Because the Flash SDK provides such a rich display API, I personally avoid this and leave any pure view event handling to the View internals to limit the public properties of Views. I could see a scenario where one such rollover needs to cause changes in multiple views, and this approach could be implemented, but i would normally rout these types updates through a submodel dedicated to UI. again, I value encapsulation above most other benefits of allowing the controller access to view properties, so i follow a standard unidirectional triangular flow. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ 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
I think a view can handle it's own rollover without concerning a controller. A controller is only there to manipulate the model on behlaf of the view. It has no interest in visuals. On 05/03/2012 14:36, Ross Sclafani wrote: i prefer to have the model update the views. preferably via event for loose coupling. the situations that a controller would alter a view in the versions of MVC i have studied are for things that are pure visual responses. like say a rollover: ROLL_OVER event on View -- calls onRollOver on controller -- sets highlight on View. Because the Flash SDK provides such a rich display API, I personally avoid this and leave any pure view event handling to the View internals to limit the public properties of Views. I could see a scenario where one such rollover needs to cause changes in multiple views, and this approach could be implemented, but i would normally rout these types updates through a submodel dedicated to UI. again, I value encapsulation above most other benefits of allowing the controller access to view properties, so i follow a standard unidirectional triangular flow. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ 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
On 05/03/2012 14:43, Merrill, Jason wrote: Fair enough, but they do sell cigarettes with a health warning these days.. ;-) Trolling is so 2 years ago. :) I don't know why you consider the comment trolling. The OP wanted to know about how to do a technique and it's seems reasonable enough to suggest why it would also help them further by explaining why the technique is bad. Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
On 05/03/2012 14:36, Ross Sclafani wrote: snip I could see a scenario where one such rollover needs to cause changes in multiple views, and this approach could be implemented, but i would normally rout these types updates through a submodel dedicated to UI. Do you have an example? I've always considered rollovers as direct feedback to the user on the element currently in focus. Any such use across multiple views eludes me for the minute. Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ 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
that is exactly how i roll.. but there are some schools that have the controller effecting all change, even temporary ones on the views. like i said, the flash SDK provides a great API for handling these things inside the views themselves. but you could imagine in a develpoment environment with no display list, using a controller to implement such a thing. in flash, though, it appears we take the same exact approach..so, you've got it perfect :D Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than a
Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
// VIEW
public class MyView implements IView {
public function update()(// do stuff);
}
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter,
Presenter doesn't know the view, only its interface.
regards,
Muzak
- Original Message -
From: Paul Andrews p...@ipauland.com
To: flashcoders@chattyfig.figleaf.com
Sent: Monday, March 05, 2012 3:11 PM
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
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
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and
the presenter is controlling multiple views, or is that wrong?
On 05/03/2012 15:33, Peter Ginneberge wrote:
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than
a Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
// VIEW
public class MyView implements IView {
public function update()(// do stuff);
}
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter, Presenter doesn't know the view, only
its interface.
regards,
Muzak
- Original Message - From: Paul Andrews p...@ipauland.com
To: flashcoders@chattyfig.figleaf.com
Sent: Monday, March 05, 2012 3:11 PM
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
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
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
___
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
I am still at the most basic level, so I 'll stick to MVC for this moment.
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews
Sent: maandag 5 maart 2012 17:01
To: Flash Coders List
Subject: Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and the
presenter is controlling multiple views, or is that wrong?
On 05/03/2012 15:33, Peter Ginneberge wrote:
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than
a Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
// VIEW
public class MyView implements IView {
public function update()(// do stuff); }
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.ht
ml
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.ht
ml#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.
html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkit
BestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter, Presenter doesn't know the view, only
its interface.
regards,
Muzak
- Original Message - From: Paul Andrews p...@ipauland.com
To: flashcoders@chattyfig.figleaf.com
Sent: Monday, March 05, 2012 3:11 PM
Subject: Re: [Flashcoders] MVC style Correction
The dependency with this is that any changes to the UI - additional
views being added or removed, requires that the controller be changed
too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
On 05/03/2012 13:57, Merrill, Jason wrote:
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
In about the simplest form:
//In the controller:
onSomeEventHandler(event:SomeEvent):void
{
_someViewInstance.update();
}
//In the view:
public function update():void
{
//Do stuff to change the view
}
Hope that helps.
Jason Merrill
___
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
i think the flash display API prevents the need for all of these additional concerns and extra classes outside of Models Views and Controllers I also loathe Interfaces. the only time i use interfaces is to allow objects with two different class lineages to be used interchangeably. like a time that i needed AIR NativeWindows to be able to snap to DisplayObjects Ross P. Sclafani design / technology / creative http://ross.sclafani.net http://www.twitter.com/rosssclafani http://www.linkedin.com/in/rosssclafani [347] 204.5714 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
If the model is updating the view, then it doesn't sound like you have a generic view at all. This can be appropriate in certain cases, but if you really want reusable View objects (like a generic scrolling text or image list view), they should be generic and abstracted from the underlying data sources (the model) - and have the data filtered through a data adapter, usually associated with the controller (or you can skip the adapter, and just bulk convert the entire model list data into generic view data, if it'll fit in memory or won't be updated in real time). In this version of MVC, to answer the original question - the controller sets up the view and wires the data source, but doesn't necessarily directly update the view (though that's who's job it is). In iOS these kinds of controllers are actually called view controllers - for maybe obvious reasons. :-) Kevin N. On 3/5/12 7:31 AM, Paul Andrews wrote: 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. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
On 05/03/2012 16:44, Kevin Newman wrote: If the model is updating the view, Not my model. My views listen for model change events. then it doesn't sound like you have a generic view at all. This can be appropriate in certain cases, but if you really want reusable View objects (like a generic scrolling text or image list view), they should be generic and abstracted from the underlying data sources (the model) - and have the data filtered through a data adapter, usually associated with the controller (or you can skip the adapter, and just bulk convert the entire model list data into generic view data, if it'll fit in memory or won't be updated in real time). I think that you're referring to the OTT pattern, favoured by many. I try and keep things simple. In this version of MVC, to answer the original question - the controller sets up the view and wires the data source, but doesn't necessarily directly update the view (though that's who's job it is). In iOS these kinds of controllers are actually called view controllers - for maybe obvious reasons. :-) Kevin N. On 3/5/12 7:31 AM, Paul Andrews wrote: 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. ___ 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
Fair enough, but they do sell cigarettes with a health warning these days.. ;-) Trolling is so 2 years ago. :) Jason Merrill Instructional Technology Architect II Bank of America Global Learning ___ -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Paul Andrews Sent: Monday, March 05, 2012 9:33 AM To: flashcoders@chattyfig.figleaf.com Subject: Re: [Flashcoders] MVC style Correction On 05/03/2012 14:13, Merrill, Jason wrote: It's the simplest form of MVC. I didn't say it was the best, I was just giving the man what he asked for. :) Fair enough, but they do sell cigarettes with a health warning these days.. ;-) Jason Merrill Instructional Technology Architect II Bank of America Global Learning -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and the presenter is controlling multiple views, or is that
wrong?
Not in GWT, no.
There's one Presenter (or Controller) for the whole app.
And then there's an MVP triad for every view.
The app controller would then for instance listen to navigation events and be responsible for displaying the view matching the nav
event.
It would do that by creating a presenter and view instance, passing the view to
the presenter, e.g.
var p:HomePresenter = new HomePresenter(new HomeView());
// you could store p for later use, so to only create the presenter
(+view) once
The presenter's constructor argument is an interface:
public function HomePresenter(view:IHomeView) {}
By using a presenter and view interface, you're able to have very dumb views, swap them out, as long as they implement the required
interface.
This also allows for easier unit testing, in GWT even without the view
implementations at all.
=
@Ross:
I also loathe Interfaces.
the only time i use interfaces is to allow objects with two different class
lineages to be used interchangeably.
That's the whole point of the view interface and why I brought it up, as you can then swap views and your presenter is none the
wiser.
I admit, interfaces aren't used very often in Actionscript, in Java however, 99% of the time you're programming against interfaces
or abstract classes.
==
Anyway.. hope I'm not confusing people who are just getting into the whole
design pattern thing too much.
If you like reading, google:
mvc vs mvp vs mvvm
MVVM: http://en.wikipedia.org/wiki/Model_View_ViewModel
Martin Fowler on PresentationModel:
http://martinfowler.com/eaaDev/PresentationModel.html
regards,
Muzak
- Original Message -
From: Paul Andrews p...@ipauland.com
To: Flash Coders List flashcoders@chattyfig.figleaf.com
Sent: Monday, March 05, 2012 5:00 PM
Subject: Re: [Flashcoders] MVC style Correction
I'm guessing we're now into nuancing the model to hold view states and the presenter is controlling multiple views, or is that
wrong?
On 05/03/2012 15:33, Peter Ginneberge wrote:
The dependency with this is that any changes to the UI - additional views being added or removed, requires that the controller
be changed too. Any change to a view could cause the controller to become broken.
For this reason, I would say it's bad practice.
Not necessarily so.
But.. you'd use an interface, which the view implements.
In which case you'd probably be talking about a Presenter rather than a
Controller :)
pseudo code:
// PRESENTER
private var view:IView;
public function ViewPresenter(v:IView) {
view = v;
// add listeners and whatnot..
}
onSomeEventHandler(event:SomeEvent):void {
view.update();
}
// VIEW
public class MyView implements IView {
public function update()(// do stuff);
}
// VIEW INTERFACE
public interface IView {
public function update();
}
GWT uses this kind of architecture:
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture.html#binding
http://code.google.com/intl/nl/webtoolkit/articles/mvp-architecture-2.html
http://www.google.com/intl/nl/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
So in GWT I usually have:
(only 1) AppController
(several) Presenter + View + Model triads
A view dispatches events to which the presenter listens.
Presenter talks to view via its interface.
View doesn't know the presenter, Presenter doesn't know the view, only its
interface.
regards,
Muzak
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
[Flashcoders] Algorithm ideas
Lets imagine I have 100 sprites scattered around the stage - no regular pattern, but generally spread evenly. My task is to remove 40 of them. That's easy, but I want to remove them as evenly as possible, so the density thins but is reasonably consistent across the stage. Any ideas? I don't know if there is a standard algorithm for this. Paul ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Algorithm ideas
On 05/03/2012 23:12, Paul Andrews wrote: Lets imagine I have 100 sprites scattered around the stage - no regular pattern, but generally spread evenly. My task is to remove 40 of them. That's easy, but I want to remove them as evenly as possible, so the density thins but is reasonably consistent across the stage. Any ideas? I don't know if there is a standard algorithm for this. No worries - I worked it out. Should have had some thinking time before posting. Paul Paul ___ 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
Thanks Cor. On Mar 5, 2012, at 4:26 AM, 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. :-) 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 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 Karl DeSaulniers Design Drumm http://designdrumm.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
