Mediating subclasses of views registered for mediation

Tim Oxley's Avatar

Tim Oxley

06 Jan, 2010 04:09 AM

If I create view subclasses, I need to manually add them to my context to have them mediated, even if the superclass is registered for mediation.

Perhaps the mediatorMap could detect if the View being added to the stage extends or implements any of its registered view classes? Or should I just deal with manually adding my subclasses to context mediatorMap?



  1. 1 Posted by Tim Oxley on 06 Jan, 2010 04:15 AM

    Tim Oxley's Avatar

    I guess that happening automatically is an issue as then you'd need to have a way to opt out if you didn't want some subclasses to be mediated, and then you have the possible confusion over which mediator to use if a different mediator is registered for the subclass.

    Explicitly mapping the view subclasses for mediation is probably better now I think about it.

  2. Support Staff 2 Posted by Shaun Smith on 06 Jan, 2010 07:57 AM

    Shaun Smith's Avatar

    Mapping mediators to abstract types would be awesome, but there is no way to do so (that we know of) without severely affecting performance.

    If you have a look in MediatorMap#onViewAdded, we have this:

    var config:MappingConfig = mappingConfigByViewClassName[getQualifiedClassName(];
    if (config && config.autoCreate)

    That code has to run every time anything is added to the display list. At the moment it's fairly cheap as we just need to check the dictionary using the added view component's qualified class name as a key. Imagine the extra work that would need to be done to determine whether the view component extends another class or implements some interface!

  3. Shaun Smith closed this discussion on 06 Jan, 2010 07:57 AM.

  4. Tim Oxley re-opened this discussion on 06 Jan, 2010 12:29 PM

  5. 3 Posted by Tim Oxley on 06 Jan, 2010 12:29 PM

    Tim Oxley's Avatar

    How many mediators do you generally have in your app? 10? 20? 30? Perhaps performance isn't always essential, and doing 30 'if x is y' statements each time something is added to the stage might not be such a bad performance hit? Of course this would be a problem if you're adding many objects to the stage (eg a particle generator), but it might not be a problem for all.

    Perhaps there could be another parameter for mapView() like "mediateViewSubclasses:Boolean = false" so it's optional.

    It's also likely that some optimisations could be performed, like keeping a Dictionary of "isNotaSubclass" mappings, so objects regularly added to the stage, like Group, ItemRenderer, etc would be checked via an "is" call but once.

    Another option might be something like the viewMap system where only the views in some specified package (I generally only have one view package) are checked against.

    Just thinking out loud.

  6. Support Staff 4 Posted by Till Schneidere... on 06 Jan, 2010 12:34 PM

    Till Schneidereit's Avatar

    The problem is that this test has to be done for _every_ DisplayObject
    that's added to the stage. That's how Robotlegs does the automatic
    creation of mediators in the first place. In a Flex application of
    medium complexity, the number of DisplayObjects can easily go into the
    hundreds or thousands, because the components create quite a lot of
    child clips to implement their behavior.

  7. 5 Posted by Tim Oxley on 06 Jan, 2010 12:52 PM

    Tim Oxley's Avatar

    Given that, perhaps rather than listening for the shotgun Event.ADDED_TO_STAGE, perhaps there should be a mechanism to register some parent object we are interested in and then listen for Event.ADDED, so we are only checking on specific objects? At least only on the children of the main context view?

  8. Support Staff 6 Posted by Till Schneidere... on 06 Jan, 2010 03:11 PM

    Till Schneidereit's Avatar

    Robotlegs only listens to ADDED_TO_STAGE on the context view, not the
    state. I should have made that clear, sorry for that.

    As for only listening to ADDED: I really like that Robotlegs doesn't
    care about the details of the display list at all. You can nest your
    displayObjects as you want without having to keep any knowledge about
    that in the application layer at all. Until someone has some bright
    idea for how to accomplish that without using ADDED_TO_STAGE, I don't
    see us switching to anything else.

    Having said that, nothing keeps you from subclassing MediatorMap and
    implementing your own mediator mapping. Shouldn't be too hard to do
    and might work fabulous for your usecases. Let us know if you want to
    go that route and need any pointers.

  9. Tim Oxley closed this discussion on 28 Jul, 2010 01:10 AM.

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