DisplayObject in Mediator Map Extension

[Kalinovych]

Hi, I think Mediator Map Extension should not cantain any link to DisplayObject. Right? Because what for else needs this overengineered stuff...

[creynders]

I'm sorry, I don't understand why it shouldn't link to DisplayObject? It's used to allow manual construction of a view's mediator. What else should we use for a view's base type?

[Kalinovych]

I'm sorry, I don't understand why a view should extends DisplayObject? Or even why mediated object should be a view at all? :)

[darscan]

why a view should extends DisplayObject? Or even why mediated object should be a view at all? :)

Hi. Neither of those statements are correct. A view does not have to be a DisplayObject - any object can be mediated. We use the term view quite loosely. Please have a look through the readme or study the source:

https://github.com/robotlegs/robotlegs-framework/tree/master/src/robotlegs/bender/extensions/mediatorMap

[Kalinovych]

Yes, I know and perfectly understand it. So what for reference to DisplayObject in MediatorMap, MediatorViewHandler?

[darscan]

So what for reference to DisplayObject in MediatorMap, MediatorViewHandler?

For convenience. 99% of the time, people will be mediating DisplayObjects.

Is it causing issues for you?

[darscan]

MediatorViewHandler integrates the MediatorMap with the ViewManager - which is specifically built to work with (or around) the Display List.

[Stray]

@Kalinovych You should only be using the api/dsl package signatures for accessing the MediatorMap functionality - the public function which exposes DisplayObject in`MediatorMap is for utility/extension building.

If you are building a utility or wrapper-extension which needs to access the MediatorMap directly, you will see there are two functions - handleView and mediate which then hand off the work to the MediatorViewHandler which has identical functions - handleView and handleItem. The more specific signature of handleView is simply making use of strong typing so that if you are only expecting to mediate things that extend DisplayObject you can get a meaningful error as early as possible.

No flexibility, non-DisplayObjects or fluffy bunnies were harmed in the making of this MediatorMap.

[Stray]

BTW - the code duplication between handleView and handleItem is deliberate inlining for performance reasons.

[Kalinovych]

I need to mediate views in Starling for web/mobile development. So I should write my own implementation of madiatorMap and viewManager?

P.S.

99% of the time, people will be mediating DisplayObjects.

So only 1% of flash developers develop apps using Stage3D and apps for mobile platforms? Or using other rendering engines different from native display list? :) Maybe. Most of 99% it is demos and small projects what sometimes event do not need to be implemented with MVC framework.

[Stray]

No - you don't need to write your own MediatorMap, you can just use the mediate and unmediate methods on the mediator map, which don't expect a DisplayObject. You will need to wire your own hooks part (to replace the MediatorViewManager) for figuring out when something to be mediated is added, but in most cases if you are using non-DisplayObject display techniques you will be performance-driven, so you'll want a bespoke solution for determining which objects get inspected for mediation, to suit your app specifically and avoid doing lots of unnecessary inspection. I'm pretty sure there is a Starling support util out there already though - just look around for it on github.

None-the-less, it's always going to be more performant to mediate your objects via a very tightly tailored bespoke solution if performance is your priority.

When Shaun said 99%, I believe he meant 99% of developers who want to use the RL2 automagic mediation rather than roll their own specific hooks. I'm in that group - and plenty of us are making very well funded and complex Air apps for desktop which rely on the conventional display list, so your comments about demos and small projects are frankly just nonsense, and a bit insulting. (My main app has been live with weekly feature updates for 4 years, has tens of thousands of users and a codebase with approaching 10k tests - not exactly trivial, and totally built on Robotlegs).

Even within projects using Stage3D or Starling, you still frequently have menus and so on which use the conventional display list - so I'd be amazed if the proportion of objects being mediated by the MediatorMap that aren't display list objects was even as high as 1%. However, if your project makes heavy use of Stage3D or Starling then the mediator pattern as implemented by Robotlegs is probably a sub-optimal solution anyway as relaying and handling events isn't usually as efficient as other wiring solutions, though they would be more tightly coupled. The objective of the Mediator pattern in RL is to achieve very loose coupling between a view and the rest of the system - which is often a good goal in an MVC app, but rarely a priority in real-time games (for example), where an entity framework like Ash is probably a better fit.

Rather than worry about what other developers are building, and whether they can justify MVC frameworks, I'd concentrate first on whether you actually even want the Mediator pattern in the parts of your own app that you're wanting to apply it to. If you do definitely need it then rolling your own alternative to the viewManager should be exactly as complex or straightforward as the bespoke problem you need to solve in the context of your app.

[Kalinovych]

Thanks for detailed answer about MediatorMap.

so your comments about demos and small projects are frankly just nonsense, and a bit insulting.

I said "Most of 99%...". I don't want to insult anyone here especially RL2 developers :) But also I'm not blind and I saw a lot of other projects and are percent is very low of project with good architecture and most of them is commercial.

However, if your project makes heavy use of Stage3D or Starling...

I always thinking that hardware rendering is more lightweight over software...

[Kalinovych]

Thanks Stray! It was quite simple to implement own view manager for Starling! RL2 rocks! :)

P.S. context.initialize(); return type is not IContext but examples for manual context initialization looks like:

_context = new Context()
    .install(MyCompanyBundle)
    .configure(MyAppConfig, SomeOtherConfig)
    .initialize();

[darscan]

context.initialize(); return type is not IContext

Ah yes, of course. We should fix that.