So you can see where I thought the prep came in handy, I needed the xml data to be loaded and parsed before we actually get into the applications target functionality and design.
Generally, you can control how you reveal your application's functionality, regardless of whether you've fetched all your data before registering the mediators.
A general process like this works well:
UI creation -> PureMVC initialization -> Model prep (Proxy registrations only) -> View Prep (Mediator registration) -> Further logic to fetch and analize configuration -> Reveal UI to user
You're free to do it anyway you like, it's just that this way takes into account the fact that often, a return from a service leads to a Proxy sending a notification that a Mediator should hear, thus, the Mediator should already be registered and listening before the call. If you want to order things differently, by all means do so, just be aware of this caveat.
I have noticed many examples I downloaded that didn't have modelPrepCommand.as and ViewPrepCommand and just goes straight to the StartupCommand.as, I think I will follow this route then as I can't see what I would actually place in these classes (model & view prepCommands.as).
It is expedient in small apps to just have the one startup command and to do both model and view prep there. However if you have a portable model, then your model package may contain its own ModelPrepCommand, so that the host application doesn't have to be responsible for proper registration of all the Proxies. It must merely include the ModelPrepCommand from your model library. In which case it makes sense to have a MacroCommand in the app that includes the local view prep and the model prep from the library.
I noticed the class path in your response for your constants was:
package net.zarqon.common.constants
I would have thought placing these in the model folder and if many a sub folder in the model folder would have been more appropriate? I would like to get a fixed folder structure, a pattern to lock down to and not deviate from, what are your thoughts on this?
These are constants used for control of the application. Zarqon is a MultiCore application and notifications are shared between modules, thus the common package. In a Standard application, you'd want to place these in your
controller package:
package net.zarqon.controller.constants
NOT the model package. Why? Because they are notifications used to control the application. They are not related to the model at all. The model describes the data you are managing. Not how you control interaction with that data.
Previously stated you said enter frame handling would be done in the views, I'm assuming that I will be creating my 3DScene (blank) as a view with its own mediator. The view having an enter frame which is handling rendering the 3D scene and 3D scene camera positioning and animation.
In most of my 3D applications, this would be where I perform animation on multiple 3D objects and on camera direction and position. Now assuming this is a view component in the PureMVC, this would mean that this view is aware of many other views (3D objects in the scene)? Is this allowed in the PureMVC? Is a view supposed to be aware and manipulate other views? What's your thoughts & suggestions on this?
Mediate objects in the scene. Have them dispatch events when they are moved, which can be turned into notifications and sent to other Mediators (and/or Commands) that need to know about the change. Same goes the other way around, lets say a mouse drag in the the viewport needs to cause a camara move. The scene could dispatch an event that its mediator hears and sends a note named MOVE_CAMARA that the CamaraMediator is interested in. The body of the note might be delta information or a newly calculated position, however you need to send it. Now your scene and your camara are decoupled.
-=Cliff>
