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
