itemRenderer inside Popup window not mediated

Allen's Avatar


26 Jan, 2010 07:11 PM


First off I want to say that Robotlegs just rocks! I also come from using PureMVC and always felt something wasnt quite right, and things were too repetitive. So I jumped on Robotlegs the day I saw it came out and have already made two projects using it, and I totally dig it. It's the shiiittt :)

So now I have this issue, in which I am using pop-up window... which by the way gets auto-mediated just fine... regardless of what this mini-article says...

Actually it just works without any of that, which is great, because when the Flex Popup Manager adds my pop-up, its gets mediated automatically... so maybe that article needs to be taken out, as its confusing.

Anyways, the current issue I am having is that inside this pop-up window, I have a TileList... yes, with a custom itemRenderer.. which are supposed to be mediated too on their own... (ie CustomItemRendererMediator)

(In fact the main reason I love Robotlegs now is because itemRenderers get mediated automatically, it's just sweet!)

But despite the fact that the pop-up window does get auto-mediated, that's where stops.. the itemRenderers in that TileList DO NOT!

The only quick solution I thought of was to create a new context just for that window, which worked like a charm. But... now its separated from the rest of my application, which is not what I want.

Any suggestions here?

Many thanks!


  1. 1 Posted by levi.strope on 26 Jan, 2010 07:41 PM

    levi.strope's Avatar

    Hi Allen.

    I have this exact same problem - for which I tried to solve a number of ways and I was not able to.

    This issue actually extends passed itemRenderer's though, and it actually affects anything on that pop-up for which you would like to have automatically mediated.

    I'm more than willing to sit down and try and solve this. I ended up giving up due to time constraints at work. I ended up putting all the logic that I needed inside my itemRenderer. Thankfully I did not have to inject anything into it and I relied solely on the itemRenderer's data property to retrieve the information I needed. I just made sure the objects within the dataprovider included this information.

    I doubt this post will help you much but it is a link to the issue I posted about this.

    Lets solve this sucker. I think if there was an eloquent way to circumvent this issue that RobotLegs would have an answer for any and all flex solutions.


  2. 2 Posted by Allen on 26 Jan, 2010 07:48 PM

    Allen's Avatar

    Ok... I came up with this solution, and it works just fine.. its just too much of a hack... but at leat it was quick and painless, and and it works

    So I created a new new Event

    public class MediatorEvent extends Event
        public static const REGISTER:String = 'mediatorRegister';
        public var view:Object;
        public function MediatorEvent(type:String, view:Object, bubbles:Boolean=false, cancelable:Boolean=false)
            super(type, bubbles, cancelable);
            this.view = view;
        public override function clone():Event
            return new MediatorEvent(type, view, bubbles, cancelable);

    and the from the actual MXML custom itemRenderer

    creationComplete="dispatchEvent(new MediatorEvent(MediatorEvent.REGISTER, this, true))"

    and then in the CustomPopUpWindowMediator

        public override function onRegister():void
            view.list.dataProvider = model.collection;
            view.addEventListener(MediatorEvent.REGISTER, register);
        private function register(e:MediatorEvent):void

    Its quite a workaround, but it works just as expected... and only took under 5 minutes to figure out.

    Would be cool if it just worked like it does with itemRenderers that ARE NOT inside pop-up windows.

    Hope this helps others with the same issue.


  3. 3 Posted by Allen on 26 Jan, 2010 07:53 PM

    Allen's Avatar

    Hi Levi...

    Thanks for your post. It was actually your post that sorta gave me the idea.. then I quickly tried it... and it worked! So I rushed back here to post it.

    Its not THE solution... as it requires an extra step... buts at least its quite simplistic.. and best of all.. works like a charm!!!

  4. 4 Posted by levi.strope on 26 Jan, 2010 07:56 PM

    levi.strope's Avatar

    I will note that I due to the complexities of itemRenderer's that that issue specifically will be a hard one to solve, unless we were able to have some sort of injectionListener that listened specifically on the popup's display list.

    I do wonder how you are able to mediate the pop-up automatically as your view. I had to do the following. I did this inside of a "DisplayformCommand".

        var distroForm:DistributionAccountForm = new DistributionAccountForm();
        distroForm.x = Application.application.width / 2 - distroForm.width / 2;
        distroForm.y = 75;
        model.removeThisWindow = distroForm;  //for removal using PopUpManager.removePopUp(model.removeThisWindow)
        PopUpManager.addPopUp(distroForm, contextView, true, PopUpManagerChildList.POPUP);
        // mediator class is automatically chosen from mediatorMap definition in the application context
        // but we still have to create it since the popup view component is not on the main displayList
  5. 5 Posted by levi.strope on 26 Jan, 2010 08:01 PM

    levi.strope's Avatar

    I just saw your reply - you posted it while I was following up.

    I tried to do something like that but I was unsuccessful - however you got further than me. I think had some error in my logic flow somewhere.

    Where do you map your mediator to the itemRenderer? I'm assuming you have a mediator for the popUp and you are doing it there?

    I'm curious now - when you remove this pop up from the display list, does it get GC'd? I assumed that if I was able to reliably mediate the mediators, what would happen should the list need refreshed based on dataBinding? Flex tries to re-use itemRenderers, and GC's some and apparently is kinda random. I'm just wondering how nice this plays in the event that, your dataprovider for the list goes from 10 records down to say, 2.

    What happens to the 8 mediators and itemRenderers that were there before? I'm curious to know if this causes a memory leak due to the specialness of the pop up being on a different display list.


  6. Support Staff 6 Posted by Joel Hooks on 26 Jan, 2010 08:04 PM

    Joel Hooks's Avatar

    Levi's solution, to manage the state of item renderers via their data property, is 100% the proper approach. Mediating Flex 3 item renderers is bad on so many levels. Item renderers should be considered private (or at least internal to their owner), with no app layer access to them what-so-ever or you are just asking for pain. This is true irrespective of framework.

  7. 7 Posted by Allen on 26 Jan, 2010 08:04 PM

    Allen's Avatar

    I do just like you that in a command... I create the new view object and then just do...

    PopUpManager.addPopUp(distroForm, contextView, false);

    And that's it... the view gets auto-mediated after that.. period.

    I tried it and it just worked the first time, say 2 or 3 weeks ago on another project I was working on.

    Try just taking out that last line, see if it works... then just trace('I got mediated!') in the mediator's onRegister() see if it works

  8. 8 Posted by Allen on 26 Jan, 2010 08:18 PM

    Allen's Avatar

    @levi Well the pop-up I just re-use through the life of the app.. I have a WindowCommand that handles that. It just gets created once, then from there on its the same window instance.
    As far at the IR's... no, I am not handling GC nor removing the mediators. Its true that those remaining 8 will still be in memory even though not used, but that really depends on your app. It may be the case that 10 seconds later those 8 have to be re-used, and thats how I imagine Flex 3 IR's where made for.

    @Joel I think Joel is right on. I read on another post you wrote that the events should be dispatched from the IR and caught at the pop-up window's mediator. Thats the way I would have gone too, keeping the IR's private.
    But in my case, these IR's have 3 comboboxes that need to be populated from data on the model, based on what the user selects. So thats why I figured mediating them was the easiest approach.

  9. Support Staff 9 Posted by Joel Hooks on 26 Jan, 2010 08:21 PM

    Joel Hooks's Avatar

    I'd consider structuring the VOs that populate the data model differently. If you need new VOs that carry the appropriate data, that is a much better way to approach it. Add the necessary collections as properties of the VOs to use as combo box data providers. There is no issue leveraging Flex's binding capabilities in your VOs within item renderers. It is much better than exposing the renderers, in my opinion (and experience).

    Easy/convenient is a slippery slope at time ;)

  10. 10 Posted by Allen on 26 Jan, 2010 08:30 PM

    Allen's Avatar

    Hey Joel,

    That is an interesting. Certainly keeps things at the data/model level without having to control the data on the IR's based on their mediator.

    I think my main impulse to go with mediating the IR's is because depending on user input, I need to...

    view.cb1.selectedIndex = -1;

    In order to get the prompt property visible again on the combox.

    If I can could control that from the VO, then its a winner.

  11. 11 Posted by levi.strope on 26 Jan, 2010 08:34 PM

    levi.strope's Avatar

    Yes Unfortunately Joel's suggestion seems to be the only clean way to do it.

    If you want to test your view/itemRenderer though I think it's kinda tough. But if you were to test the data going in, then you can rely on integration tests to exercise the view.

    I do like your solution though, I wouldn't call it a hack so much as calling it what works. Thank you for posting it - I'm definitely putting it in my RL toolbox.

  12. 12 Posted by Allen on 26 Jan, 2010 08:49 PM

    Allen's Avatar

    Just for clarification... I was wrong about that not needing to call the createMediator() method. I made a mistake. I had put that in a WindowCommand and totally forgot how it even worked, and somehow today I looked at that Article and thought, I didnt have to do that... So sorry about misleading you on that Levi.

    here is my WindowCommand, which was made with making one single-instance windows

    public class WindowCommand extends Command
        private static var windows:Dictionary = new Dictionary();
        private static var opened:Array = new Array();
        [Inject] public var event:BaseWindowEvent;
        public function WindowCommand()
        public override function execute():void
            var center:Boolean;
            var window:BaseWindow;
            switch (event.type)
                case BaseWindowEvent.CLOSE:
                    opened.splice(opened.indexOf(event.window), 1);
                case BaseWindowEvent.OPEN:
                    window = windows[event.klass] as BaseWindow;
                    if (window == null)
                        window = windows[event.klass] = new event.klass();
                        center = true;
                    if (opened.indexOf(window) === -1)
                        PopUpManager.addPopUp(window, contextView, window.modal);
                        if (center)
                    if (

    And here is the BaseWindowEvent

    public class BaseWindowEvent extends Event
        public static const CLOSE:String = 'windowClose';
        public static const OPEN:String = 'windowOpen';
        public static const SAVE:String = 'windowSave';
        public var window:BaseWindow;
        public var klass:Class;
        public var data:Object;
        public function BaseWindowEvent(type:String, window:BaseWindow=null, klass:Class=null, data:Object=null, bubbles:Boolean=false, cancelable:Boolean=false)
            super(type, bubbles, cancelable);
            this.window = window;
            this.klass = klass;
   = data;
        public override function clone():Event
            return new BaseWindowEvent(type, window, klass, data, bubbles, cancelable);

    The BaseWindow is just an MXML base to base of my window views. Sorry about my erroneous comment again on this matter.

  13. Joel Hooks closed this discussion on 28 Jan, 2010 08:14 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac