All services in my MVC strategy are extensions to the controller tree that controllers use to get data from outside to put in the model. In my world, models don't "do" they "hold" so outside of their inner framework mechanisms, they are only made up of getters, setters, and vars. All public methods in my MVC apps belong in the controller, or occasionally displayobject subclasses that are used by views, but not view subclasses themselves.
Division of duties: Models - public vars/accessors Controllers - public methods for manipulating model's public properties. Views - private vars/methods to implement display logic based on model updates. Again I can only speak about how wildly effective my approach is, but I'm sure there are merits to others where mine succeeds in simplicity. Strokes / folks... 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 Mar 26, 2012, at 1:37 PM, "Merrill, Jason" <jason.merr...@bankofamerica.com> wrote: > I wouldn't put it in the controller, it a data thing. I create a class that > loads in XML as a service class, and have the model load the service, > dispatching an event when done that the controller picks up on. MVCS. > > 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 Creighton, > Gerry > Sent: Monday, March 26, 2012 1:25 PM > To: Flash Coders List > Subject: Re: [Flashcoders] MVC - ScreenManager > > I thought that it should be in the controller. Just wanted to be certain. > > Thanks, > > -Gerry > > On 3/26/12 1:21 PM, "tom rhodes" <tom.rho...@gmail.com> wrote: > >> well, either you can add an Service to MVC and get MVCS, or perhaps >> your main app controller would load it if it's config stuff and set up >> models accordingly. i imagine you have a model ready and waiting to >> store the info in? >> >> basically you want to keep app logic out of models, they just want to >> be about data. so either do it in a controller that updates your model, >> or have a controller use a service (so you don't bloat the controller) >> which updates a model. >> >> On 26 March 2012 19:07, Creighton, Gerry <gcreigh...@discmakers.com> >> wrote: >> >>> If I'm loading XML would that be done in the model or the controller? >>> >>> >>> On 3/9/12 9:06 AM, "Glen Pike" <g...@engineeredarts.co.uk> wrote: >>> >>>> :D >>>> >>>> On 09/03/2012 05:20, Karl DeSaulniers wrote: >>>>> If you can't take the Henrik, get out of the kitchen.. lol >>>>> >>>> >>>> _______________________________________________ >>>> 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 > > ---------------------------------------------------------------------- > 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
