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