I have just created a hello world example and have a few questions if anyone can clarify a few things before I proceed that would be great.

Q1. I have a stage mediator registered from my ApplicationMediator, this stage mediator dispatches mouse up notifications. I am randomly placing the hello world text on x and y. Where should the random x and y be calculated? Is it best practice to place the random positioning logic for the placement of the hello world view component in the ApplicationMediator via its handleNotification function where the view component is instantiated or should this be done via a command? If it's a command how do I get the reference of the view component added to the stage for x and y placement?

Q2. Registering mediators inside mediators is this correct? or should they all be registered in a centralised place for better management?

Q3. If mediators register and handle other mediators, should they be able to obtain references to other mediators? If yes how do we get the reference to the created mediator?

Q4. If for example I am building an application that has an empty container as a view, to which I add views to it later. Where would the logic go for adding view components to a view? If this is a mediator, im guessing a command would be created for listening to added for listening to events from the mediator for handling things to do when added and when removed?

Q5. If I have a 3D Scene as a view (which is default blank), and then create separate view components which can be added to the 3D Scene view, should the 3D scene view be a view or a mediator? Im guessing mediator for calling the view component (3D scene), then same mediator to listen to events and have code in it to add 3D objects to the view component or is this a more complicated scenario of many commands, mediators and views?

For a moment there while typing this I thought I clarified things for myself, then I re-read it and now think the opposite lol...

To visualise things I created some process flow class diagrams to illustrate how I think the PureMVC is actually laid out.

Q1. I have a stage mediator registered from my ApplicationMediator, this stage mediator dispatches mouse up notifications. I am randomly placing the hello world text on x and y. Where should the random x and y be calculated? Is it best practice to place the random positioning logic for the placement of the hello world view component in the ApplicationMediator via its handleNotification function where the view component is instantiated or should this be done via a command? If it's a command how do I get the reference of the view component added to the stage for x and y placement?

I'd probably have the StageMediator be interested in a PLACE_OBJECT_RANDOMLY note, and handle it by taking the DisplayObject out of the body of the note, adding random x/y coords and adding it to the stage. Any other actor could create the display object and send the note.

Quote

Q2. Registering mediators inside mediators is this correct? or should they all be registered in a centralised place for better management?

Well, it depends on a number of factors. If the view hierarchy all exists at startup, is very flat (only one or two levels deep) then for expediency you might register all the mediators in one shot in your view prep phase. But that isn't an across-the-board, works-in-all-situations answer.

If your hierarchy is deep, and/or some of the mediated components have creation deferred, then it's better to let mediators register mediators.

The philosophy here is that encapsulation of the view is violated by that one command that knows the whole hierarchy. A mediator's relationship with its view component, is by design somewhat more intimate. We can say that the first level of children under the view component in question are top level public properties of that component, part of an API of sorts. The mediator can access them without being considered too intrusive. When it then wraps a mediator around that component, the same concept applies.

Quote

Q3. If mediators register and handle other mediators, should they be able to obtain references to other mediators? If yes how do we get the reference to the created mediator?

The best practices doc points out that you should not retrieve mediators and invoke methods on them, but rather send notifications to them. This is their intended form of communication with the rest of the application, and you should follow it wherever you can, because it keeps things loosely coupled in the view, which makes for more reusable mediator/view component pairs. I'm working in an app right now where the big media creation app has been developed over several years. Now that it's grown so large, they're building a lightweight viewer app in Flex and offline viewing app in AIR, both of which need to reuse many pieces of the bigger creation app. Because of tight coupling in the original code, we're finding it difficult to reuse many of the pieces because it was always assumed that they would only ever be used in the creation app. So, the point is if you keep things loose by default (sending notes rather than retrieving a mediator and invoking a method, then if you ever do need to reuse things you'll thank yourself.

Quote

Q4. If for example I am building an application that has an empty container as a view, to which I add views to it later. Where would the logic go for adding view components to a view? If this is a mediator, im guessing a command would be created for listening to added for listening to events from the mediator for handling things to do when added and when removed?

No, don't make commands into event listeners. They're intended to be instantiated, executed and garbage collected. This is their lifecycle; they are not long-lived objects. The mediator listening to the container that just had objects added to it IS a long-lived object and is the perfect place for such a listener.

Quote

Q5. If I have a 3D Scene as a view (which is default blank), and then create separate view components which can be added to the 3D Scene view, should the 3D scene view be a view or a mediator? Im guessing mediator for calling the view component (3D scene), then same mediator to listen to events and have code in it to add 3D objects to the view component or is this a more complicated scenario of many commands, mediators and views?

A 3D scene is just a view hierarchy. Mediate it accordingly. The scene probably has a mediator. If you put some player or nonplayer actors in there, they probably have mediators. A table or a wall or a tree, probably not so much unless those objects are going to be interacting with the rest of the app in some complex way, generating events that in turn have effects on other objects in the scene.

Quote

To visualise things I created some process flow class diagrams to illustrate how I think the PureMVC is actually laid out. This look correct?

More or less, yes this is your basic flow. Getting into MultiCore or using the StateMachine may change this picture a little bit.

I'd probably have the StageMediator be interested in a PLACE_OBJECT_RANDOMLY note, and handle it by taking the DisplayObject out of the body of the note, adding random x/y coords and adding it to the stage. Any other actor could create the display object and send the note.

"PLACE_OBJECT_RANDOMLY note"? - I assume by this you mean a "placeObjectRandomly(do:DisplayObject)" function but where? I assumed a command which would have been run in the "NotificationHandler" function of the ApplicationMediator?

Quote

Any other actor could create the display object

"Actor"? Is this the pureMVC communities ref to a Mediator?

And finally my picture of what happens in my applications mediators is now this, just to clear things a little more, is this correct?

Application Mediator (On my hello world application) - Register any mediators required - Instantiate any views - Setup "notification handler" - "Notification handler" exec commands via sendNotification via the facade to position "sprite" - "Mouse button stage up" notification: Instantiates hello world view text component and sends a notification via sendNotification for a command to position HelloWorld text randomly on x & y(how can the command get the view components reference for positioning? & how can the command get the stage? or reference to any required mediators?)

and for my next test build with preloader, closer to a template I will work from would be something like

"PLACE_OBJECT_RANDOMLY note"? - I assume by this you mean a "placeObjectRandomly(do:DisplayObject)" function but where? I assumed a command which would have been run in the "NotificationHandler" function of the ApplicationMediator?

That is a notification named PLACE_OBJECT_RANDOMLY. Notifications are commonly referred to as notes for short.

Quote

And finally my picture of what happens in my applications mediators is now this, just to clear things a little more, is this correct?

Application Mediator (On my hello world application) - Register any mediators required - Instantiate any views - Setup "notification handler" - "Notification handler" exec commands via sendNotification via the facade to position "sprite" - "Mouse button stage up" notification: Instantiates hello world view text component and sends a notification via sendNotification for a command to position HelloWorld text randomly on x & y (how can the command get the view components reference for positioning? & how can the command get the stage? or reference to any required mediators?)

Well, you'd actually instantiate any views before registering mediators, presumably you'd be passing those views to their mediators.

And what I was suggesting in my previous post was that the StageMediator would respond to the PLACE_OBJECT_RANDOMLY note by setting the object's x and y to random values and setting it on the stage. You don't need to send it off to a command for that.

Quote

QuoteAny other actor could create the display object

"Actor"? Is this the pureMVC communities ref to a Mediator?

No, that's a general OOP term for a class with some clear role. In this case it would be a Command or a Mediator.

Quote

Application Mediator (On my preloader application)

You can't mediate the preloader. It comes before Flex has finished initializing, and creating its view hierarchy. Only after that do we startup the PureMVC apparatus.

Excellent! thank you for all this help and info, has been pivotal, I find so many contradictions in what should go where googling all this stuff..

I have a framework called the AFTC, which is a modular framework which is a combination of factory, singleton and observer patterns. Included are 1 x XML doc for sprite/mc application container structure, 1 x XML config, embedded assets manager, preloader via bulkloader, various managers for assets and fonts etc. The AFTC simply allows a dev to simply copy and paste the base template and create a folder for each module of the application to work within for each module of their application. All of this weighs in around 12Kb, I am wishing to re-create this using the PureMVC so I can just copy and paste my template app and have access to all the essential managers, assets and utilities from my AFTC framework, so I can keep Rapid Application Development just using the PureMVC.

Hopefully last question before I get back into test app city.

Narrowing down things in a more general sense would lock my application and all future applications I build into this layout:

Commands

Call functions from proxies

Send notifications for mediators to update their view components on data notifications received from proxie (failed or changed)

Mediators

Add view components to the stage/display (to give references to their relative mediators)

Loading progress event dispatching caught by commands (would a command dispatch another event for a mediator to pick up for progress loading for example or would a developer skip this and let the mediator listen to the proxies progress event?)

Vo (not quite sure on this classes role, just a list of variable declerations which are accessible?)

Proxy (not quite sure on this classes role, just a list of variable declerations which are accessible?)

Regarding my template app for future projects, I would:

In prep model - I will setup proxy for config xml (local file)

In prep model - I will setup proxy for assets xml (local file)

In prep model - I will setup proxy for containers xml (local file)

In prep model - I will setup proxy for accessing assets from bulkloader

Mediators are not code-behind classes. They shouldn't perform much if any logic. If it's complex at all, send the component of in the body of a command to be processed instead.

Quote

Loading progress event dispatching caught by commands (would a command dispatch another event for a mediator to pick up for progress loading for example or would a developer skip this and let the mediator listen to the proxies progress event?)

Yes, feel free to have mediators listen directly for proxy notifications. The view is unavoidably dependent upon the model; it has no other reason in life than to display and let you interact with the model.

Quote

AssetPreloaderMediator - Execute preloader mediator

As I mentioned in the previous response you can't mediate the preloader.

ok seems I'm not thinking on the right path here.... :\ I'm a bit confused on the roles of the mediator and the command. Is this correct?

MediatorsMediators do nothing apart from instantiate other mediators passing view components to them and listen to notification events which the mediator would call a function in the corresponding view components to update themselves, animate etc

CommandsAre the applications performance logic.So, they get references to mediators and view components to perform logic on them (or would the logic of animation be partly done in the views?). How would 2 balls colliding in a 2D or 3D scene work? Would a command hold multiple references to multiple mediators and the view components performing logic on them eg enter_frame events if sometimes necessary? Would a command handle enter_frame logic?

Regarding preloader.I am wanting to include bulkloader in my puremvc template application, my picture on how to do this now is to, create bulkloader proxy, bulkloader mediator, bulkloader view (progress bar). A command would be run which would setup a proxy, then the command would run a mediator which in turn would setup a preloader ui? Is this correct?

In response to your question:

Quote

Is this a multicore project? If you're loading a module that uses PureMVC, it needs to be, so that there is a separate facade for each module.

No, I am in the habit of referring to a RIA,Webpage etc's pages, different sections as modules.

Would a command hold multiple references to multiple mediators and the view components performing logic on them eg enter_frame events if sometimes necessary?

Remember, commands are short-lived. They are instantiated when they are triggered and when their execution is complete they are GC'd. So they wouldn't 'hold references to mediators', though they could fetch them when need be.

More likely, the view component produces an event which the mediator hears and passes the component in the body of a notification to a command, where the command performs some logic on the component.

Quote

the command would run a mediator which in turn would setup a preloader ui? Is this correct?

It's the other way around. Mediators send notes that 'run' or execute commands, which are short-lived actors. Mediators are registered and remain as long-lived actors listening to their view components.

A quick way to clear up confusion about the roles, responsibilities and collaborations of the framework actors is to visit the overview presentations and/or read some of the documentation at http://puremvc.org/content/view/98/189/

Question 1If the above is correct, would a view contain an enter frame event listener and function to handle enter frame animation?

Question 2,3,4,5For a 3D scene, on collision detection of lets say randomly 10 3d objects, each with different animations depending on the type of object pair collision, where would the enter frame collision detection code be placed, as a mediator shouldn't perform logic and a command is short lived? or is this an exception?

Mediators can also retrieve and interact with Proxies for simple updates.

Quote

Question 1If the above is correct, would a view contain an enter frame event listener and function to handle enter frame animation?

Yes. The View Component can and should encapsulate as much of its own behavior as possible.

It only needs to initiate communicate with the app when it needs to let the rest of the app know something has happened to it (such as a collision or a button press) or it needs data (country and state selected, need specific counties to populate a combo) or wants to add or update data to the Model (form submission).

The app only needs to communicate with the view component to feed it data (inject the country list into a newly shown form or tell it to change to a new view state based on a change in application state).

Quote

Question 2,3,4,5For a 3D scene, on collision detection of lets say randomly 10 3d objects, each with different animations depending on the type of object pair collision, where would the enter frame collision detection code be placed, as a mediator shouldn't perform logic and a command is short lived? or is this an exception?

Collision detection should happen in the component. The component should send an event with the object it's crashed into as a property. The Mediator should hear this event and pass it on to a command (via notification) for evaluation. This command might figure out what the objects need to do; maybe one bounces off and the other explodes. The command could then call the bounce method on one and the explode method on the other or some such. And possibly call a Proxy to bump up the score if this was a missile and an enemy that collided.