Hi All,

[This kind of follows on from this thread: http://knowledge.robotlegs.org/discussions/problems/50-mapping-medi...]

Sorry for the long rambling post. The app I'm working has a fairly complicated view structure, and I'm not completely happy with the way it's hanging together.

I have a multi window AIR app, which I'm currently porting to Robotlegs. The app is designed to run on a machines with between 1-6 six physical screens attached. Each screen contains between 5-20 different views. Events within each screen are pretty much self contained within that screen. Two screens do communicate with each other, but apart from that, there's no need for inter-screen events. There are some, 'all screen' events (Arrange and ScreenSaver). There are also two classes of utility window (an Exposé style window management view, and a ScreenLauncher).

So far, I'm remodeling the app into 6 modules. One for each screen. This feels right, but it does result in lots of code. Each display has it's own Module, Context, ModuleMediator, etc. So be it.

The utility windows are simpler. These both run in the main context and have their own (manually created) mediators.

To show/hide any window, my main app mediator calls show/hide methods on the main view -- e.g. myFoo.showBah() returns a ref to the new window's stage. This basically hides the multiwindow nature of the app from the mediators, which feels right. It does mean my main mxml file needs show/hide methods from every window. Not sure this is good.

After calling show, the app mediator asks the mediatorMap to create a new mediator for the new stage -- e.g mediatorMap.createMediator(newStage);. I think this is ok, but I'd like to see what other solutions people use for manual creation of mediators. I though about mapping to a createNewMediatorCommand, but this seems like overkill, right?

My legacy code also contains a singleton WindowManager (singleton with a static factory method). This is basically a helper that activates, cleans-up, orders and arranges the windows. It also responds to events from the Exposé view and the ScreenLauncher (currently unmediated). Windows instances are basically injected in to the WindowManager via an addWindow method. Maybe this is ok to leave as is, but I'd like to see if there's a more Robotlegs-ish approach. Not sure why, but I'm always suspicious of manager classes and this one feels like it's making the view layer very thick. Any ideas here appreciated.

Thanks for yr time/thoughts/etc.

Cheers,

J