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

Show Posts

* | |

  Show Posts
Pages: 1 [2]
16  Announcements and General Discussion / Architecture / Re: invoking AsyncMacroCommand w/ "body" display Obj argument? on: December 28, 2008, 03:18:00
Duh   :) still learning sorry
17  Announcements and General Discussion / Architecture / Re: invoking AsyncMacroCommand w/ "body" display Obj argument? on: December 28, 2008, 03:09:18
oh ya right of course - retrieveProxy. I was still clinging to my old ways I guess. Thanks.
18  Announcements and General Discussion / Architecture / Re: invoking AsyncMacroCommand w/ "body" display Obj argument? 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
19  Announcements and General Discussion / Architecture / Re: invoking AsyncMacroCommand w/ "body" display Obj argument? 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
20  Announcements and General Discussion / Architecture / invoking AsyncMacroCommand w/ "body" display Obj argument? 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
21  Announcements and General Discussion / Architecture / Re: Modularity - Why Shell and Canvas? on: December 23, 2008, 04:03:46
The problem was not necessarily with the demo - perhaps I just wasn't getting it. I think I was over thinking the design of the example. But this last clarification helps. Thanks.
22  Announcements and General Discussion / Architecture / Re: Modularity - Why Shell and Canvas? on: December 22, 2008, 12:23:53
OK thanks Cliff. Maybe I sounded like I was being critical - didn't mean to.

Let me rephrase - in your opinion could the shell and canvas be combined? In what circumstances would you consider it helpful to have both of these classes? Can you provide an example/generalization of the kind of duties that these classes should be responsible for?

Or perhaps the focus of this example code was more on the usage of Module and I should ignore this portion of the design. Thanks!

Peter
23  Announcements and General Discussion / Architecture / Modularity - Why Shell and Canvas? on: December 17, 2008, 08:29:27
Hi -

I'm interested in using the multicore version for my AS3 only app. It looks like I can use the ModuleBase class without the overhead of Flex framework required by Module - barring this I will simply load a swf.

I've been pouring over the Modularity example and I can't quite work out why I should need both a shell and the canvas? It seems to me like there is some redundancy here and so I'm wondering what potential scaling scenario I am missing?

This seems further complicated by the Shell consisting of both a view and a mediator. I'm inclined to start with just one mediator(shell) and one view(canvas) and then refactoring when the need arises. Anyone have any thoughts on this? Thanks.

Peter
24  Announcements and General Discussion / Architecture / Re: PureMVC proxy/model singleton vs. Cairngorm ModelLocator? on: October 04, 2008, 02:48:14
Hi Cliff -

Thanks for the thoughtful response. I agree about the tendency for ModelLocator to get disorganized. Things have also tended to be complicated when I've used the model to store state data, e.g. active elements, state flags, etc. This state data is not really part of the domain model, but still needs to be stored somehow. Perhaps I should be moving this data to the Mediator, but this is problematic for persisting state across sessions. I'm still looking to improve my approach here.

As I mentioned I've tried to impose some order by structuring a composite model. This model contains references to various typed data objects that are intuitively named and structured at the cost of being tightly coupled with a specific view. In this sense ModelLocator serves as a sort of dtd for deserialized objects, but there is a price to pay for this.

I suppose I should be looking at package structure to provide the overview. But I'm not happy with FlexBuilder outline view for package exploration. Here is one place I feel Visual Studio is a better IDE with class view.

I think I will try to embrace the Pure MVC approach fully at first and see how much I miss the dtd. Thanks again.

Peter
25  Announcements and General Discussion / Architecture / PureMVC proxy/model singleton vs. Cairngorm ModelLocator? on: October 03, 2008, 02:25:02
Hello -

I am interested in building a project with Pure MVC. I have built several projects with Cairngorm which I find to be architecturally similar in some respects. My question pertains to the general strategy for the data model in PureMVC.

In Cairngorm I have been using the ModelLocator singleton as a composite for the application model. As such I find this practice helpful as it is declarative and provides a centralized overview of the application domain model.

In contrast the Pure MVC framework does not appear to have a single model singleton defining model data. Instead the model singleton allows for proxy objects to be registered via the facade. Are there any best practices regarding the structure and registering of model logic? The examples provided are small and do not address a strategy for scaling application model logic.

How, for example, would I store and access something like application configuration data in Pure MVC? In the RSS reader sample a FeedVO is utilized. Suppose I wanted to cache a collection of these on the client for a history feature. Where would these go?  Can anyone share/shed light on this subject? Thanks!

Peter
Pages: 1 [2]