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: Modularity - a PureMVC AS3 MultiCore Demo  (Read 18857 times)
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« on: March 07, 2008, 09:49:25 »

This demo illustrates simple usage of the PureMVC AS3 MultiCore Framework using Flex Modules.

The demo is located at http://trac.puremvc.org/Demo_AS3_MultiCore_Flex_Modularity

The author is Cliff Hall.
Logged
coursevector
Courseware Beta
Newbie
***
Posts: 4


View Profile Email
« Reply #1 on: March 11, 2008, 11:25:05 »

Trying to figure out how to use this with Flash and am having trouble initializing the app. If i'm starting my app from the timeline, i can't pass in a class name per se. Such as:

var facade:ApplicationFacade = ApplicationFacade.getInstance("MyApp");
Won't work because MyApp is not a class, it's just a key i would like to use for that core.
For the correct class this app is being instantiated in would be MainTimeLine, but i can't reference that data type for the other classes that recieve the notification at startup.

I have this line in my startup command:
var stage:DisplayObject = note.getBody() as DisplayObject;
also have tried
var stage:*= note.getBody();
and
var stage:MainTimeLine= note.getBody() as MainTimeLine;
which don't work.

Any suggestions, i'm kinda confused.
Logged
coursevector
Courseware Beta
Newbie
***
Posts: 4


View Profile Email
« Reply #2 on: March 11, 2008, 01:11:56 »

Got it working. It seems I'm able to pass in whatever name i would like on the getInstance(), the problem that was stopping me was having to update all my mediator and proxy classes to use the initializeNotifier function. Also to fix the SubCommand bug as mentioned in my other post.

This is all i have on my timeline:

var facade:ApplicationFacade = ApplicationFacade.getInstance("MyApp");
facade.startup(this);

and on my startup function:

public function startup(app:DisplayObjectContainer):void {
        sendNotification(ApplicationFacade.STARTUP, app);
}

in my PrepViewCommand:

var stage:DisplayObjectContainer = note.getBody() as DisplayObjectContainer;

If i just use the DisplayObjectContainer type, everything seems to be kosher.
Logged
zzal
Newbie
*
Posts: 7


View Profile Email
« Reply #3 on: April 03, 2008, 05:00:55 »

Great! I've been able to build this demo with XCode 3.1.
That's a set of features I was looking for (the modularity) for my future application.
I have a question regarding the demo: one feature is to be able to load external swfs at runtime, is it? The demo right now seems to be encapsulated into one swf. Is there any special implications regarding this?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: April 04, 2008, 01:22:44 »

Zzal,

Yes, the current demo simply instantiates the modules at startup in order to simplify and make it more understandable.

The focus of the demo is to prove that multiple PureMVC Cores can co-reside happily within the same Flash VM without conflict, and to show how to create interfaces for the Cores to talk to each other. Dynamic loading/unloading of Flex Modules or SWFs will be the subject of future demos.

-=Cliff>
Logged
prototypic
Newbie
*
Posts: 1


View Profile Email
« Reply #5 on: May 12, 2008, 04:09:44 »

Cliff,

I'm currently building an application that needs the use of dynamic loading/unloading of Flex Modules. I'm using the Tab Navigator extensively, and I was wondering if you could elaborate a little on proper use of this, rather than waiting for a demo ;).

Should I be instantiating and registering each mediator and proxy at runtime? How would you correlate a mediator instance with a proxy instance? Or should I just be using some sort of collection that contains all the new modules, which would lead me back into just using PureMVC Standard.

I know this is a tall order, but any help would be much appreciated.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #6 on: May 14, 2008, 05:54:31 »

I'm not sure exactly what the question is here. Is it about tab navigators, loading/unloading modules or instantiating mediators and proxies?

Having a collection that holds the modules wouldn't make it ok to drop back to the standard version if the modules and the app are all PureMVC. The Singletons would still collide.

-=Cliff>   
Logged
ricardokirkner
Jr. Member
**
Posts: 18


View Profile Email
« Reply #7 on: June 02, 2008, 11:44:15 »

Hi Cliff,

I woud like to ask you if you plan to extend the Modularity demo to include modules loaded at runtime. I ask this, because I would really like to see how you approach this issue (which includes loading and unloading flex modules, and doing all the registration/unregistration tasks related to housekeeping), since every demo I saw you wrote was quite a beauty (from the cleanliness and well-laid out code).

thanks for the feedback, and keep up the good work :-)

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



View Profile WWW Email
« Reply #8 on: June 02, 2008, 12:04:02 »

Modularity focuses on the interface/contract school of thought with regard to module communications and with shell to module communications.

PipeWorks focuses on the use of Pipes as a means of loosening the coupling a bit and allowing modules/cores that don't have references to each other communicate.

Most likely I will do another demo and possibly a utility that focuses on loading/unloading and management of modules. CodePeek taught me about trying to cram too much functionality into any one demo. It becomes hard to take the learning points from when so much is going on.

-=Cliff>
Logged
ricardokirkner
Jr. Member
**
Posts: 18


View Profile Email
« Reply #9 on: June 02, 2008, 12:06:33 »

ok, nice to hear. in the mean time, could you give me some thoughts on how I should approach this issue in order to try to solve it by myself (until I get the chance to peek into your code)?

thank you again
Logged
filipelima
Newbie
*
Posts: 1


View Profile Email
« Reply #10 on: June 05, 2008, 02:00:05 »

Hi Guys,
Yes... I think my current problem falls under this topic in loading/unloading of modules at runtime.

First I've been using PMVC Standard which even for someone still rookie to design paterns, it is a beauty to use.

Heres my quest:

The application which I need to use as a module is a videoplayer that I built in pmvc_standard, and later/now converted to  using the multicore libraries.
The task is to load this module on user request, alas runtime.

In my understanding so far I know i could register the module's mediator's and proxy's under the shell application's facade, but that would basicaly render it into one whole standard application, which kills the purpose of multicore.

So im a bit lost on what would be the best approach/solution to this.

Cheers,
Filipe
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #11 on: June 05, 2008, 06:34:04 »

Though we're not loading the modules, just instantiating them, the Modularity and Pipeworks demos show a couple of different ways of managing modules and their communications with the main app/shell at runtime.

In Modularity, the Module and the Shell have a reference to each other. The Shell is really a component in the main app. They both expose interfaces so that the Shell knows the methods it can call on a Module and visa versa.

In PipeWorks, the Shell and Modules don't communicate over interfaces, but using Messages sent over Pipes.

In either case it is assumed that the main app / Shell will load or instantiate the modules.

-=Cliff> 
Logged
ricardokirkner
Jr. Member
**
Posts: 18


View Profile Email
« Reply #12 on: June 09, 2008, 12:21:16 »

What are the benefits/drawbacks of each approach? What I mean is, how do I know which of the two approaches suits me best?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #13 on: June 13, 2008, 06:45:23 »

The benefit of using pipes is that you can isolate modules better. They need only understand a message protocol of your devising. They don't need to know anything about each other or share a reference to each other.

If you were writing a platform that would support third party widget development, for instance, you'd want to keep those modules as isolated as possible, and pipes could help.

If you are modularizing a large enterprise application you may prefer to go the interface route simply because you want to interact with the module synchonously. You trust your shell and module code to play well together and are simply after the benefits of modularization of discrete functionality into separate, simpler projects. If modules need to talk to each other a lot, mind your inter-dependencies by putting interfaces in a common place and keeping them in sync with implementation classes!

You can always mix and match interfaces and pipes for module communications. In the PipeWorks demo, you can see that the shell requests of the LoggerModule its log window and log button, which are sent back asynchronously. It's all protocol. (Encoded in the UIQueryMessage class)

But the Prattler is a different story. The shell/main app's PrattlerModuleMediator invokes a method 'exportFeedWindow' on the module. It results in the same thing, the window being sent via pipe message to the shell, but it could've just returned it synchronously. it was simply easier to receive it via pipe.

Modular programming is a powerful thing. But the patterns for doing it successfully in Flex and Flash and PureMVC are still emerging. Interfaces are natch; the most obvious abstraction that allow us to cleanly separate yet maintain a useful collaboration.

Pipes is another useful abstraction that is the very core of what makes unix so powerful. It seemed like a pretty good fit for modules if you're after maximum isolation.

For instance if I had a spreadsheet in csv format with column and row headers and I wanted to cross-foot the report (tally rows and columns then make sure the column totals add up to the row  totals) In unix,  I might arbitrarily chain together a pipeline of commands to dump the file, drop the first line, then cut out the first column, send the results through awk to add up the rows and tack on the total column and accumulate the total row, then through awk again to crossfoot. With a little tweaking and looking around the man pages for option help, it'd be done. And none of the commands need to know anything about each other. Its very data-centric all about taking input acting on it and passing the torch.

Of course an RIA with a named pipe scheme can be quite a bit more complex and so now we begin the job of finding ways to manage this complexity and still derive enough benefit to make it worthwhile.

-=Cliff>
Logged
Pages: [1]
Print