Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Variable for app in AppFacade?  (Read 6760 times)
arlo
Newbie
*
Posts: 3


View Profile Email
« on: November 05, 2008, 03:26:23 »

Hi all-  I'm trying to delay my ViewPreparation, to have it wait until the ModelPreparation is complete.  Since the ViewPrep command is no longer called from the Facade.startup(app) step, I'm wondering how to get an object variable of the app itself to a command not called directly by the facade.  This probably makes no sense, but it's a really simple notion in my mind: to have some simple way of returning the app itself as a variable, to be able to prepare the view outside of the facade.startup(app) methodology.

Thanks!
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: November 05, 2008, 05:03:25 »

I didn't fully understand your point, but will do my best to explain how and why the startup process is the way it is in most PureMVC apps. I'm going to use a flex app as a reference.


1. The MXML Application creates itself and all its children and its properties.

2.One of those properties is initialized to a reference to the ApplicationFacade.

3. Calling getInstance on the facade causes the singleton instance to be created.

4. During the facade's initialization, the Model, View and Controller singletons are created as well.

5. The controller is initialized with your initial command mappings.

6. The main Application calls creationComplete, which is handled by calling facade.startup(this), passing a reference to the now-ready Application view component hierarchy.

7. The startup method of your facade sends the STARTUP notification, triggering the Controller to run StartupCommand. The reference to the Application is the body of this notification.
 .
8. The StartupCommand is either;
8a. A SimpleCommand that prepares the Model tier followed by the View tier.

Or

8b. A MacroCommand with ModelPrepCommand and ViewPrepCommand as children, in that order.

9. During the model prep phase, proxies are created and registered. Generally they should not immediately send data requests, as this could result in response before the view is prepared.

10. During the view prep phase, mediators are created and registered for the existing view components that need them. This may be done;
10a. All from within a the command by accessing the properties of the Application (passed in the STARTUP note body) and passing them to the cosntructors of the corresponding mediators.

or

10b.In an  ApplicationMediator which is created with the reference to the Application. The ApplicationMediator then creates and registers the other mediators.

11. A final notification is sent at the end of view preparation that causes the initial configuration / data / assets to be loaded now that all actors are present and accounted for. Mediators and Commands are registered and ready to respond, and Proxies are ready to be queried, to request and receive data, and to send change notifications.

12. Up until this point, the view should be in a splash mode; possible user interactions should be held off until any necessary initial remote communications are complete. 

13. Once any remote data has been received, and the view informed, the view should transition into the user interface so that input can be collected.

14. Gestures and input at the view are handled by mediators, which may;

14a. Interact with Proxies to update or query the model,

Or
14b. Send notifications whic are;

14bi. Acted upon by other interested Mediators, which may change the state of their view components

And/or

14bii. Acted upon by a Command which may update and query the model or send notifications to view be acted upon by Commands and/ or Mediators.

-=Cliff>
Logged
arlo
Newbie
*
Posts: 3


View Profile Email
« Reply #2 on: November 05, 2008, 05:24:37 »

Thanks Cliff.  I'm coming from what Flex might people call a Flash/Agile builder perspective, and am slowly getting this more comp-sci approach. 

I suppose my problem lies in that I'm completely delaying the View commands until my model data is loaded and parsed.  Instead, I think I need to be commencing with the View stuff, but like you said, sort of make it wait until I can send another command to populate/draw the components.

I really hated pureMVC when we were first tasked to build with it (and the learning curve is steep, believe you me), but I'm seeing the structural efficiencies that on a larger scale would help track problems down and allow for changes.  I'll post again if I fall into a pot hole with the approach.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: November 06, 2008, 05:24:36 »

No problem, feel free do drop by anytime :)

Yes, the learning curve can be steep when you are first learning OOP concepts and this seemingly complex framework at the same time. Plus, Flash's IDE definitely reinforces one workflow while Flex/Air are totally different - all code, no timeline. How do you put a button on frame 42? Seems like a totally natural question to a Flash developer, but an enterprise developer answers Who cares about frame 42?

Once you're on the train, you'll really start rolling though, its worth it. The hints at maintainability you're seeing are definitely real!

-=Cliff>

 
Logged
Pages: [1]
Print