I'm dynamically creating view objects and would like the Mediator to be mediating the view as soon as possible.

rickcr's Avatar

rickcr

24 Mar, 2010 11:09 PM

I'm noticing some odd behavior in our current app and I 'think' I know what the issue is... it appears that at certain points during the app's lifecycle certain view mediators are not mediating a dynamically created view until too late. To try to break it down to the short version, we're building some view dynamically based off a class name that is found in some XML:

for each(var pxml:XML in prompts) {
    var pmt:Prompt = UiHelper.instantiateUsingClassName([email blocked]());

UIHelper is creating the class as follows:

var classToInstantiate:Class = getDefinitionByName(className) as Class;
var myClassFactory:ClassFactory = new ClassFactory(classToInstantiate);
var myObjectInstance:* = myClassFactory.newInstance();
return myObjectInstance;

For all the potential views I have them mapped to Mediators in a BootStrap class that runs early on:
eg:

mediatorMap.mapView(EntitiesPrompt, EntitiesPromptMediator);

The issue is that I'm not sure exactly when the ADDED_TO_STAGE event fires for the Mediator to be tied to its view, but it seems as if it's coming to late in some cases. After the views are dynamically created some methods get called directly on the views for doing some populating of things the view needs. Some of those view methods often trigger a dispatch event that I want the mediator of the view to be aware of, but since the mediator hasn't even called its onRegister the handlers aren't in place to pick up the event.

Everything should work ok I believe if I could force the appropriate Mediator to be in place right after I do:

var prompt:Prompt = UiHelper.instantiateUsingClassName([email blocked]());

At that point I have my view instance (prompt) but I really don't know the class of the Mediator at that stage - although its name can be determined based on some convention (eg prompt.className()+"Mediator") (I haven't looked in AS to even know if .getClassName exists but I assume there is something similar.)

Any tips on what I'd need to do to force the Mediator to be in place and onRegister called as soon as possible?

  1. 1 Posted by Jason Dias on 25 Mar, 2010 02:02 AM

    Jason Dias's Avatar

    what if you did mediatorMap.createMediator(pmt); right after you create it?

  2. 2 Posted by rickcr on 25 Mar, 2010 03:43 AM

    rickcr's Avatar

    Thanks Jason, I modified the code to do what you mentioned in a Command, but the onRegister is not occurring into much later than I would expect. I was hoping doing

    mediatorMap.createMediator(pmt);

    would immediate trigger the onRegister of the Mediator of that view, but that doesn't seem to be the case.

  3. 3 Posted by rickcr on 25 Mar, 2010 03:51 AM

    rickcr's Avatar

    ... as a side note, I do see the constructor of the mediator immediately called after manually stating mediatorMap.createMediator, however, as mentioned, the onRegister isn't firing until much later.

  4. Support Staff 4 Posted by Shaun Smith on 25 Mar, 2010 01:27 PM

    Shaun Smith's Avatar

    If the view is a Flex component, onRegister will only be called when that component fires it's creationComplete event:

    http://github.com/robotlegs/robotlegs-framework/blob/v1.0.3/src/org...

    You have a couple of options:

    1. Use the onRegister hook in the Mediator to tell the view component when it is safe to start doing it's business. So, the view component would have an init() method, and the mediator would wire up it's listeners and then call view.init() in onRegister. This would be the recommended approach.

    2. Override preRegister. This hook is called as soon as the mediator is created and hands responsibility over to the mediator to decide when it is ready. The mediator calls onRegister on itself when it has decided that the view component is ready. Make sure to call super.preRegister, or onRegister in your override. This approach feels hacky.

    I highly recommend option 1. It's pretty bad practice for a view component to start doing things the moment it is created - it limits options for re-use, pooling etc.

  5. 5 Posted by rickcr on 25 Mar, 2010 02:43 PM

    rickcr's Avatar

    Thanks so much for the reply Shaun. You made me rethink my architecture (doing it now more inline with option 1 as you suggested.)

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

Keyboard shortcuts

Generic

? 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