Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
May 29, 2017, 08:16:54 AM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
Pages: [1]
Print
Author Topic: ApplicationFacade.startup() vs AppStartUp Command  (Read 5367 times)
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW
« on: February 14, 2012, 11:22:18 PM »

Ok, this is sort of a back to basics question but, put simply, what belongs in your concrete facade's init() method other than a sendNotification() to trigger your AppStartUp Command?

And what should you put in your AppStartUp command that shouldn't go in your concrete facade's initializeController/View/Model() methods?

The reason I am asking is that all kinds of initialization code is creeping into these two spots (with some bleed over into initializeController/View/Model()) and I need to implement some kind of best practice or standard for my project.

For example, here are some common things being put willy-nilly in the framework startup logic:

  • Flashvars proxy registration
  • Class variable/Singleton settings (eg: ToolTipManager.showDelay = 0;)
  • Context menu configuration
  • All kinds of view class Mediator registration -- does the Mediator need data from a Proxy to initialize?  Yes?  Then wait for the proxy notification to register it.  No?  Then register it in the concrete facade... wait, is this really the best way?
  • LoadUpUtility stuff -- currently done in AppStartUp Command

Some of the stuff related to the Flex framework I feel like it should perhaps go in the Application mxml file.  Maybe configuring the ContextMenu should as well.  But sometimes the ContextMenu depends upon the flashvars which I want to access via the FlashVarsProxy... so into the framework code it goes!

Suffice to say, I'm curious where people would put the above logic to keep things tidy and sensible.  This may require a review of what the concrete facade functions role should be, etc.
« Last Edit: February 16, 2012, 06:41:52 PM by jpwrunyan » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2867



View Profile WWW
« Reply #1 on: February 15, 2012, 10:04:15 AM »

Quote
what belongs in your concrete facade's init() method other than a sendNotification() to trigger your AppStartUp Command?
Usually we call that convenience method startup().

In a very complex app, dependencies in the startup order can get hairy no matter what your choice of framework (or lack thereof).

But in PureMVC, the recommended startup process goes like this:

1) Prepare the Controller. This can happen in a command or in the initializeController method of the facade, and consists of registering all your commands.

2) Prepare the Model. This consists of registering Proxys and they should not go ripping off and making service calls as soon as they're created or registered. They should wait for invocations from Commands or Mediators for doing anything, because if they got a service return before Mediators involved in the response are registered, you'll miss it.

3) Prepare the View. This usually consists of registering Mediators, and upon registration, Mediators frequently request data from the already-registered Proxys.

I recommend picking up a copy of the ActionScript Developer's Guide to PureMVC, as I covered this in a pretty high level of detail there, and particularly into how to reduce the size of your ApplicationFacade to nearly nothing.

You can peruse the example project from the book for free by downloading it from http://oreil.ly/puremvc

-=Cliff>
« Last Edit: February 15, 2012, 10:05:52 AM by puremvc » Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW
« Reply #2 on: February 15, 2012, 09:39:03 PM »

3) Prepare the View. This usually consists of registering Mediators, and upon registration, Mediators frequently request data from the already-registered Proxys.

One thing I want to clarify.  In step 3 you are talking about Facade.initializeView() correct?  The thing that gives me pause is that this method does not have local access to any view components.  Unlike startup() which is passed a reference to the Application view component.  As a result, I have been registering my ApplicationMediator in startup() and then having ApplicationMediator finish registering the remaining Mediators for its internal parts.  I am uncertain now if this is the most logical way.

I will try to order the book this weekend.  It will take at least a week to get here from overseas.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2867



View Profile WWW
« Reply #3 on: February 16, 2012, 09:46:55 AM »

Quote
In step 3 you are talking about Facade.initializeView() correct?
No. Model and View preparation usually happen in Commands. You can do Command preparation in a command as well, but your concrete Facade will need to register at least a startup command, so it is handy to register them all in the facade.

In the O'Reilly book, I show how to minimize your Facade and do all your MVC prep in commands. Fortunately the example code is available in their repository, so you can just have a look...





« Last Edit: February 16, 2012, 10:22:28 AM by puremvc » Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW
« Reply #4 on: February 16, 2012, 06:41:29 PM »

Awesome.  This is actually exactly what I was wondering about.  At the start the best practices gave me the impression that the concrete facade should be minimalist but along the way me and others on my team have allowed stuff to creep in there.

So we have mostly favored the AppStartUp Command but it has bloated (and spilled over into facade startUp()).  I have personally moved a lot of command registration and proxy registration from AppStartUp into the initializeModel()/View() methods.  But your Startup MacroCommand is very appealing--I  actually remember it now from a tutorial I looked at a year ago.

By the way, am I right in assuming that the facade methods are not ever meant to be overridden except in very rare cases where you might want to modify the core PureMVC logic/behavior for some reason?  For example, inserting your own class as the View singleton.

Anyway, thanks.  I felt this was a very basic question and now that I see the answer in plain text, it seems obvious.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2867



View Profile WWW
« Reply #5 on: February 17, 2012, 08:44:52 AM »

Quote
am I right in assuming that the facade methods are not ever meant to be overridden except in very rare cases where you might want to modify the core PureMVC logic/behavior for some reason?  For example, inserting your own class as the View singleton.
Yep.  That's the reason. In retrospect it was wrong of me to advocate even the command registration happening there, mainly because of broken-window theory. One reasons, if command registration can go there, then why not other things can as well. People end up putting all kinds of cruft in the Facade as a result. But the Facade doesn't need to know every actor in your app. Its role is to provide an interface to the Model, View, and Controller without having to work with those actors directly, and to provide a means for the system to be started up from the outside. That's it.
Logged
Pages: [1]
Print
Jump to: