Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
- Should the overall view hierarchy be managed in one mediator? I imaging if we're loading and removing entire panels there needs to be some parent to handle that transition. But which actor is actually processing the 'addChild' & 'removeChild' commands? Are we adding child directly to stage or to GlobalView?
...I've always thought of a command as a discrete chunk of procedural code and I don't see how it would function as, what seems to me, a mediator for the StageMediator... Why not just cut out the command and have everything talk to the StageMediator directly?
Or it could be heard by the Mediator for another view component that has already been added to the Stage, who adds the new component as a child of its own view component. You can create your entire view hierarchy this way and not have to have the StageMediator manage every single placement and not have multiple classes manipulating the Stage.
Could this be a decent implementation of added views to the stage?
Or would I be causing the applications view structure/hierarchy to lean too heavily on Mediators. Put another way, this mode of view instantiation pairs the display hierarchy of the application directly to the PureMVC framework. I'm not sure that is the best approach.
Only have Mediators that actually expect to add components to their children listen of course...
Would it not be cool to create an AbstractMediator to listen for any and all ADD_TO_STAGE notifications, and allow concrete subclassed Mediators to respond if necessary?
/** * List Notification Interests. * <P> * Adds subclass interests to those of the JunctionMediator.</P> */ override public function listNotificationInterests():Array { var interests:Array = super.listNotificationInterests(); interests.push(ApplicationFacade.EXPORT_FEED_WINDOW); return interests; } /** * Handle Junction related Notifications for the PrattlerModule. * <P> * For the Prattler, this consists of exporting the * FeedWindow in a PipeMessage to STDSHELL, as well as the * ordinary JunctionMediator duties of accepting input * and output pipes from the Shell.</P> * <P> * Also send messages to the logger.</P> */ override public function handleNotification( note:INotification ):void { switch( note.getName() ) { // Send the LogWindow UI Component case ApplicationFacade.EXPORT_FEED_WINDOW: var prattlerWindowMessage:UIQueryMessage = new UIQueryMessage( UIQueryMessage.SET, PrattlerModule.FEED_WINDOW_UI, UIComponent(note.getBody()) ); junction.sendMessage( PipeAwareModule.STDSHELL, prattlerWindowMessage ); break; // And let super handle the rest (ACCEPT_OUTPUT_PIPE, ACCEPT_INPUT_PIPE, SEND_TO_LOG) default: super.handleNotification(note); } }