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