A really nice explanation.
I tried to find your EastAsMVC after being on your site, is it on the way?
Also, what comes first, ie. how do the models, controller and Views find
out about each other?
Does everything register with the (single) controller?
John
On 16/02/2012 00:05, Ross Sclafani wrote:
I am an MVC purist, I always proceed as follows:
Models should ONLY store information, particularly the state of the application
and any data retrieved from disk or the network.
Views hold a reference to a model, watch it for updates, and respond to those
updates by rendering the model in its current state. 'rendering' could refer to
manipulating the display list in flash, outputting some text to stout (or
trace) serving up some JSON from a server app, whatever way of expressing the
state of the model your app requires. Views are also responsible for handling
events that occur in their domain, and forwarding them to the appropriate
Controllers.
Controllers exist to manipulate models. The only acceptable way to alter a
model is via a controller. Whether its storing data from a Web service in the
model, or altering the state of the app in response to user interaction, the
controllers hold all of the business logic that define how the app behaves.
Ideally, in AS3, the models consist of no methods except accessors that
retrieve values from private vars and store values there and notify subscribed
views of the update. Event dispatcher is a fantastic base class for a model.
Equally, wherever possible, a controller should only consist of methods.
Properties are for the model.
This sets up a unidirectional flow of interaction and display. The controller
populates the model, the model notifies the views, the views change. The
changed view incites some user interaction, the view tells the controller what
the user wants to happen, and the controller alters the state of the model
accordingly, which then notifies the views to change, and so on and so forth.
Ross P. Sclafani
Owner / Creative Director
Neuromantic Industries
http://www.neuromantic.com
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
347.204.5714
On Feb 15, 2012, at 1:46 PM, "Merrill, Jason"<jason.merr...@bankofamerica.com>
wrote:
Calculations would not be in the controller, they would be in the Model.
Sometimes you can justify them being in the view if it's related to the view.
Calculations are also in a Service class if they are part of a service in some
way.
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 David Hunter
Sent: Wednesday, February 15, 2012 1:32 PM
To: Flash Coders List
Subject: [Flashcoders] MVC style
Hello list,
If I am making an application with MVC pattern and calculations are needed to
be performed on the data when the user interacts with the application, would
you:
do the calculations in the Model?
create a separate class that handles the calculations and puts the results in
the model?
do the calculations in the Controller?
looking forward to hearing people's thoughts on this,
david
--
David Hunter
www.davidhunterdesign.com
+44 (0) 7869 104 906
_______________________________________________
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
_______________________________________________
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
