I think you're right that LoginController is the wrong place for this. When I was asking about the end goal, I meant more conceptually what you're trying to accomplish by having this scroller. Without more information that cuts to the heart of that and also more about how your Classes are actually relating with one another, I still can't give you a better implementation than dispatching a custom event with the MovieClip in it.
However, I think that there's a bad design smell about that--why on earth do these controllers and views have references to these MovieClips they're not showing themselves? There has to be some deeper "something" about how these could be made/managed without this awkwardness. Where are these components that you're adding to the scroller when they're not in the scroller?
In the absence of that type of information, I can ony give you an example of how to implement my first (admittedly sort of crap) suggestion.
public interface IEventBusClient { function get eventBus():IEventDispatcher; function set eventBus(value:IEventDispatcher):void; } |
public class MovieClipEvent extends Event { pubic static const SEND_TO_SCROLLER:String = 'sendToScroller'; public var movieClip:MovieClip; public function MovieClipEvent(type:String, mc:MovieClip) { super(type, false, true); movieClip = mc; } override publlic function clone():Event { return new MovieClipEvent(type, movieClip); } } |
public class SomeController implements IEventBusClient { protected var _eventBus:IEventDispatcher; public function get eventBus():IEventDispatcher { return _eventBus; } public function set eventBus(value:IEventDispatcher):void { _eventBus = value; } protected function invokeScroller(e:SomeEventType):void { if (_eventBus && someMovieClip) { _eventBus.dispatchEvent(new MovieClipEvent(MovieClipEvent.SEND_TO_SCROLLER, someMovieClip); } } } |
public class ScrollerController implements IEventBusClient { protected var _eventBus:IEventDispatcher; protected var _scroller:ActualGreenSockTypeGoesHere; public function get eventBus():IEventDispatcher { return _eventBus; } public function set eventBus(value:IEventDispatcher):void { if (_eventBus != value) { if (_eventBus) { _eventBus.removeEventistener(MovieClipEvent.ADD_TO_SCROLLER, updateScroller); } _eventBus = value; if (_eventBus) { _eventBus.addEventistener(MovieClipEvent.ADD_TO_SCROLLER, updateScroller); } } protected function updateScroller(e:MovieClipEvent):void { //remove old clip using whatever the greensock api says var mc:MovieClip = e.movieClip; if (mc) { //add movieclip to scroller using greensock api } } } |
You can then set eventBus on instances of these Classes to the display list or to an event dispatcher that you make for the purpose of providing communication. I like to have a separate event dispatcher that serves as a communication backbone in the "data" space (and by that I mean the model and controller classes), but I also will sometimes populate that variable with a reference to the display list or a more local event bus depending on what I'm doing--the thing that makes this technique tremendously powerful is that you can get a lot of flexibility just based on what object you pass in as the event bus.
I think I've made this suggestion before, but in case I haven't, you may want to consider using RobotLetg, since it can automate the process of providing those references.