Title: Getting started - proxys & ModelPrepCommand Post by: Darcey on January 26, 2011, 04:13:45 Hi,
I am building my template application and wanting 3 xml files to be loaded before my application starts to do anything related to the project it will be implemented on. I have in my ApplicationStartupCommand.as the following: override protected function initializeMacroCommand() :void The proxy will load a local xml file, what I need is the command to listen for notifications (success or fail). On success: addSubCommand( EmbeddedAssetsPrepCommand ); Which will just call a singleton of a embedded assets class and then add the final subCommand ( viewPrepCommand ), which in the puremvc template registers the application mediator. Question 1: How should a command listen for a notification if I can't use override public function handleNotification( note:INotification ):void ? Question 2: Or should I just ignore the possibilities of failure at this stage of the puremvc and assume that the xml file will always be in existence? And just place all subCommands in the ApplicationStartupCommand? Question 3: If I were to have a large scale application with many many many events being listened for and reacted upon, would the ApplicationFacade still have hard coded in constants for each of these events? Thanks Darcey Title: Re: Getting started - proxys & ModelPrepCommand Post by: puremvc on January 26, 2011, 11:41:49 // I want a sequential command process hereDon't follow what prep you need on embedded assets. They're embedded, what's to prep. Perhaps I just use a different process from you. The simplest way I know to handle them in Flex is to create one or more classes of static constants, with each being an embedded object. Those are referenced in the view components, and Flex builds the view hierarchy first. So for me embedded assets are implicitly 'prepped'. Here's an example: package net.zarqon.common.constants Model prep should not be going off to get data, by the way, it should simply register the Proxies. Wait until the View has been prepped before invoking any service calls out of those proxies. Why? because usually, the Proxy, upon receiving a service result, will send a notification. And it's likely that one or more Mediators will be interested. But if you haven't prepped the View by registering those Mediators, you can't be sure they'll be registered in time to hear the note from the Proxy. How should a command listen for a notification if I can't useCommands are intended to be short-lived actors, instantiated and invoked for a single function and then garbage collected. Mediators and Proxies by contrast are long-lived actors, they are instantiated, registered and live until the end of the program or when they are specifically removed. I believe the answer to the previous question obviates the need for this command to listen for the Model prep to finish because that's all synchronous code if you don't make any service calls during Model prep. If I were to have a large scale application with many many many events being listened for and reacted upon, would the ApplicationFacade still have hard coded in constants for each of these events?No. You'd probably move them to a separate constants file. Like: package net.zarqon.common.constants -=Cliff> Title: Re: Getting started - proxys & ModelPrepCommand Post by: Darcey on January 26, 2011, 02:06:48 Ah, this is the process of what I am working to achieve:
Before anything visual appears
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. 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). The EmbeddedAssetsPrep came from an example I downloaded exampling usage of the twitter api. I guess that's not quite correct then. Question: 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?I will alter my template application to work as follows, let me know if you have see anything wrong with this:
I will create "NotificationConstants.as" in the model folder for holding all notifications bar "STARTUP". Question My first real world test application of the above PureMVC skeleton will be a very basic 3D application. Regarding some details you gave me in my previous post ("getting started"). 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? An example would be a 3D scene with a carousel and hover camera, where I click on an item in the carousel. Each item is a view component, and has its own animation for rotation tweens but the positions in the 3D scene of each view would be manipulated in relation to camera direction, camera position and which item in the carousel was clicked resulting in quite varied animation. Thanks again for all your help, Darcey Title: Re: Getting started - proxys & ModelPrepCommand Post by: puremvc on February 01, 2011, 01:57:34 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: 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. 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> |