A few things

[cliffhall]

Hi Mike,

I forked and did a bit of work on this, which I've checked in on my fork, but ultimately, I think a better mechanism should be used than the PageProxy. I was going to try and remove all references to the AppConstants and BottomNavView from it but ultimately this should be combination of business logic in Commands working with a Mediator, similar to the way the StateMachine works. It is a view contraption. The history could be stored in the data property of a framework proxy instance, but the Proxy shouldn't be doing a lot of stuff that at its heart is view mechanics. That's for the other tiers.

Also, I noticed that the PageProxy defined a bunch of data for pages which I don't see when I check out the demo. On the demo I see grids with rows and each page's grid is a slightly different shade of grey. What's up with that? Vestigial remains of a previous approach?

-=Cliff>

[mbritton]

Handling window.resize in PageProxy was a convenience thing. I figure this is where all page data are maintained "for resize and page change events". In your proposed scenario, would a mediator handle the resize and page change events, then send a notification to a command? It's a valid approach, for sure, but I'm not sure what the mediator would use as its view component. Would it be the entire app (an App Mediator)? Would it not have a view, and exist solely to direct notifications controlling view mechanics?

ViewportComponent, into which pages are loaded, is where the creativity comes in. In the current scenario, pages should all show up and be navigable on the horizontal (inside pagesX). The color changes you're seeing are the same pages loaded into pagesY. The idea is there's a background (all pages loaded into pagesY) where artwork is placed, and a foreground overlay (all pages loaded into pagesX) where text and titles go. Things move around and animate into place, perhaps at different speeds. I want to create variations of this approach, where pages appear in different ways, and make the choice a config property. In theory this distinguishes the app from other solutions (jQuery Mobile and Sencha).

[cliffhall]

"It's a valid approach, for sure, but I'm not sure what the mediator would use as its view component. Would it be the entire app (an App Mediator)? Would it not have a view, and exist solely to direct notifications controlling view mechanics?"

Yes, this is the idea. Although a Mediator subclass 99.999% of the time has a view component and mediates between it and the rest of the system, sometimes they need to take on other mediation roles within the application. I think this is one of those times.

Consider the AS3 StateMachine class:

https://github.com/PureMVC/puremvc-as3-util-statemachine/blob/master/src-multicore/org/puremvc/as3/multicore/utilities/statemachine/StateMachine.as

A mediator subclass, it has no view component, but it maintains the current State as well as the map of all States and their valid transitions between each other. How does that map get built? In an application, a command processes the XML that describes those states and uses an FSMInjector to create, populate, and register the StateMachine.

https://github.com/PureMVC/puremvc-as3-util-statemachine/blob/master/src-multicore/org/puremvc/as3/multicore/utilities/statemachine/FSMInjector.as

The responsibility for parsing the XML for the state machine and turning it into States falls to other actors (a command and a custom Notifier). That XML could come from the disk, a service, or be created in the command, but that's of no consequence to the StateMachine class, which still performs a mediation role, albeit slightly more complex than a normal Mediator.

Inbound notifications to the StateMachine trigger changes to the current State and a series of outbound notifications about the transition, allowing other actors to respond at the right times, and possibly stop the transition with another notification. It does some logic, but it is purely mediation logic.

StateMachine does maintain some data - something normal Mediators for view components should really avoid - but it is data no other actor needs to have access to or be able to modify. It is not Model data - it is application state data and that belongs to the running application not any specific component. Instead of retrieving this data, other actors can follow the state changes and respond accordingly.

[mbritton]

Merged your changes. Much better.

I'm worried that creating a new mediator and command for updating the model on window.resize, moving that functionality from PageProxy, could impact performance. There can be hundreds of events as a browser window is resized. A command would be instantiated each time a mediator sends its notification.

Could an immutable command be created? The command pattern doesn't specify if a command should be destroyed.

[cliffhall]

I agree that could be a performance issue if a command is instantiated for each resize event.

Regarding the ICommand life-cycle, with PureMVC, it is intended not to be stateful. It should be created when needed and destroyed afterward. So things like reading templates and the like could be in a command/proxy, but the Mediator could be used as the long-lived actor that directs the page changes.

Right now, I'm not 100% sure what the PageProxy's full set of responsibilities is. Maybe you could list those out and we could figure out what belongs where.

You can also create a custom Notifier subclass that the Mediator tends that has logic in it. Like the FSMInjector class mentioned above. It is able to send Notifications, but isn't a command.

[mbritton]

A custom Notifier that receives and broadcasts for certain events. PageResizeNotifier, and its mediator. Yeah that is a good solution because the rest of the apps' actors have the option of subscribing.

I already send a notification for window.resize, without a significant performance impact. Logical next step.