PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: log2e on August 13, 2008, 11:20:43



Title: Handling FlashVars in PureMVC
Post by: log2e on August 13, 2008, 11:20:43
I blogged on my approach to handling FlashVars in a PureMVC application:

http://blog.log2e.com/2008/08/13/handling-flashvars-in-puremvc/ (http://blog.log2e.com/2008/08/13/handling-flashvars-in-puremvc/)



Title: Re: Handling FlashVars in PureMVC
Post by: pperon on August 14, 2008, 08:03:22
Great post. Thank you.

I too have been thinking about how best to handle flashvars and have a slightly different approach.

I treat flashvars as I would anything else that comes from my View; by dispatching a custom event and letting the mediator send a notification out to the rest of the application with the flashvars as payload.

My creationComplete handler looks like this:
:
private function creationCompleteHandler():void {
   ApplicationFacade.getInstance(NAME).startup(this);
   dispatchEvent(
      new CreationCompleteEvent(
         CreationCompleteEvent.COMPLETE,
         Application.application.parameters
      )
   );
}

Then inside the Application's Mediator I simply handle the CreationCompleteEvent and send a Notification which is processed by a InitFlashVars Command.

:
private function creationCompleteEventHandler(event:CreationCompleteEvent):void {
   sendNotification(ApplicationFacade.INIT_FLASHVARS, event.flashvars);
}

My original feeling was that I didn't want the Facade to do anything but... well, be a facade.

To be honest, I'm still trying to "think in PureMVC" and don't really know if one way is better than another. Thoughts?

-Phil


Title: Re: Handling FlashVars in PureMVC
Post by: puremvc on August 14, 2008, 09:26:47
Since those parameters may be used at anytime during runtime, I usually set up a ParamsProxy that takes the parameters object and exposes the parameters that we expect to be there with getters. This way any actor can retrieve the Proxy and access its parameters in a typesafe way that the compiler can check.


The ParamsProxy is easy to build for your app and looks something like this (insert your own parameters, of course):

:
package com.me.myapp.model
{

import org.puremvc.as3.multicore.patterns.proxy.Proxy;

/**
* Parameters Proxy.
* <P>
* Maintains the parameters object that corresponds to
* the <code>FlashVars</code> passed into the Application
* via the OBJECT/EMBED tag in the HTML wrapper.</P>
*/
public class ParamsProxy extends Proxy
{
public static const NAME:String = "ParamsProxy";

/**
* Constructor.
*/
public function ParamsProxy( params:Object )
{
        super ( NAME, params );
}


/**
* Get the vendorName parameter.
*/
      public function get vendorName():String
      {
      return params.vendorName as String;
      }
     
/**
* Get the appName parameter.
*/
      public function get appName():String
      {
      return params.appName as String;
      }
     
/**
* Get the appVersion parameter.
*/
      public function get appVersion():String
      {
      return appVersion as String;
      }
     
      /**
      * The parameters supplied to the main application.
      * <P>
      * There are two sources of parameters: the query
      * string of the Application's URL, and the value
      * of the FlashVars HTML parameter.</P>
      */
      public function get params():Object
      {
      return data as Object;
      }
     
}
}

In the StartupCommand, since I have a reference to the Application, and parameters is a direct public property, I just register a ParamsProxy at that time:

:
package com.me.myapp
{
import com.me.myapp.MyApp;
import com.me.myapp.model.ParamsProxy;
import com.me.myapp.view.ApplicationMediator;

import org.puremvc.as3.multicore.interfaces.INotification;
import org.puremvc.as3.multicore.patterns.command.SimpleCommand;

/**
* Startup.
*
* Creates and registers the initial Proxies and Mediators
*
* @param note the STARTUP notification
*/
public class StartupCommand extends SimpleCommand
{
override public function execute(note:INotification):void
{
// Retrieve the Application reference and register the ApplicationMediator 
var myApp:MyApp = note.getBody() as MyApp;

// Register the ParamsProxy
// It maintains the FlashVars and initial QueryString parameters
facade.registerProxy( new ParamsProxy( myApp.parameters ) );

// Register the ApplicationMediator
facade.registerMediator( new ApplicationMediator( myApp ) );

}

}
}

That's it. Go home, no more to see here.

-=Cliff>


Title: Re: Handling FlashVars in PureMVC
Post by: pperon on August 14, 2008, 01:30:45
Ah ha! Of course! Clean and simple. Love it.

Thanks, Cliff.


Title: Re: Handling FlashVars in PureMVC
Post by: drummer on September 03, 2008, 04:55:42
Cliff, if I'd like to stay in line with the PureMVC conventions, would it be legal to access the ParamsProxy from another Proxy (e.g. my ApplicationProxy or whatever)? I haven't quite figured this out.

A more general form of this question would be: may proxies access other proxies through the facade?

Thanks.


Title: Re: Handling FlashVars in PureMVC
Post by: puremvc on September 04, 2008, 01:15:21
Not a problem. Go for it.

-=Cliff>


Title: Re: Handling FlashVars in PureMVC
Post by: hush on January 12, 2009, 08:19:50
Hello, Cliff!
This is my first post/reply so to start off I just wanted to express my warm feelings for PureMVC and your awesome incredible work that you've done and are still doing to keep everybody happy here! ;]
Now on the topic: just noticed a small detail that's missing in appVersion getter in ParamsProxy:
Shouldn't it be:
:
return params.appVersion as String;
not
:
return appVersion as String;


Title: Re: Handling FlashVars in PureMVC
Post by: puremvc on January 12, 2009, 02:30:52
Yes, good catch on that. Part of the problem with coding in a forum post box ;)

-=Cliff>


Title: Re: Handling FlashVars in PureMVC
Post by: mico on March 11, 2010, 07:49:27
Amazing how natural PureMVC handles flashvars here! Thanks a lot, Cliff!