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: invoking AsyncMacroCommand w/ "body" display Obj argument?  (Read 9443 times)
pebanfield
Full Member
***
Posts: 33


View Profile Email
« on: December 26, 2008, 11:01:27 »

I would like to pass a reference to the stage via the body argument in my extended AsyncMacroCommand as is done with simple commands. But the pattern doesn't seem to allow for this as initializeAsyncMacroCommand() is called from the constructor with no arguments.

I'd like one of my subcommands to contain a stage reference so that I can access the Flashvars collection via LoaderInfo.parameters. I'm passing some values with Flashvars and some via xml configuration files.

I'm thinking my best option will be to pass a ref to the display object in my AsyncMacroCommand derived class constructor where I will also call super to initialize the command array and invoke initializeAsyncMacroCommand. Does this sound reasonable? Is there a better way to do this? Perhaps I'm missing the point of this utility and so no body object arg should be required? Thanks.

Peter
Logged
pebanfield
Full Member
***
Posts: 33


View Profile Email
« Reply #1 on: December 27, 2008, 05:43:27 »

Ok so extension won't work - subCommands is not public and execute has been made final. But this was seeming like a hack anyhow.

The good news is that I've realized I can access the root property in the subcommand by calling retrieveMediator. I've called getViewComponent on the IMediator instance (in this case my ApplicationMediator but any will do i guess) and casted the returned object to a DisplayObject and bang I can access root.

Upon reflection I suppose you could consider reading Flashvars as a platform specific data access utility and so it is not in the spirit of PureMVC to try to account for it? With my current approach I'm considering the LoaderInfo(app.root.loaderInfo).parameters collection like any data source, but I'm accessing it directly in the command as a proxy and delegate seem like overkill?

Peter
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: December 27, 2008, 06:24:48 »

You can simply register a 'FlashVarsProxy' with the data at startup. The StageMediator can do this since it has the Stage reference, so that no other actor needs to know the Stage to get this data. Then commands like the one you're trying to get this data to ae able to get it via th Proxy like all other data in the app.
-=Cliff> 
Logged
pebanfield
Full Member
***
Posts: 33


View Profile Email
« Reply #3 on: December 27, 2008, 11:40:48 »

Ah yes this does seem better/looser coupling. I was using a singleton model object to store the Flashvars. In my case I have some values that are sometimes assigned to via a config.xml and sometimes set only in Flashvars.

In some cases the Flashvars overwrite the config values. This is partly due to the need to support a legacy design and also because it is sometimes easier to set values in a server-side page via the the Flashvars.

This makes the singleton model object handy because of the need to assign values to it from different commands/proxies. Does this sound ok? Any thoughts on this? Is there a better alternative? Thanks!

Peter
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: December 27, 2008, 11:13:17 »

Any reason not to just make it a proxy and register it like other proxies? You can easily retrieve it from any command, proxy or mediator. This means you don't need to treat it any differently that the rest of the data in your app. Which will make it easier for those future devlopers who try to figure out this part of the legacy later on down the line.

-=Cliff>
Logged
pebanfield
Full Member
***
Posts: 33


View Profile Email
« Reply #5 on: December 28, 2008, 03:09:18 »

oh ya right of course - retrieveProxy. I was still clinging to my old ways I guess. Thanks.
Logged
pebanfield
Full Member
***
Posts: 33


View Profile Email
« Reply #6 on: December 28, 2008, 03:18:00 »

Duh   :) still learning sorry
Logged
Pages: [1]
Print