PureMVC Architects Lounge

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

The demo has historically been located here: http://trac.puremvc.org/Demo_AS3_MultiCore_Flex_PipeWorks
The project has been moved here: https://github.com/PureMVC/puremvc-as3-demo-flex-pipeworks/wiki

The author is Cliff Hall.

Hi Folks,

This demo currently has a little bug that crept in with some refactoring done late last night. Messages from the PrattlerModule are currently being doubled in the log. But the messages from the shell are only sent once.

This isn't a pipes utility problem, it's been working fine and in fact the utility has a full set of unit tests of its own. Just some little niggly thing in the demo, I'll get worked out shortly. But I wanted to get this out there as there are a lot of people looking at Pipes and wondering what to do with it...

-=Cliff>

Alright, no problem. Took longer to republish than to fix. Version 1.1 is now available and working as advertised.

Soon I will post more on the theory of operation, but see the release notes page for highlights before diving into the code.

-=Cliff>

This is an excellent demo. I found a small bug:

Class: org.puremvc.as3.multicore.demos.flex.pipeworks.shell.view.ShellJunctionMediator

When handling the switch case ApplicationFacade.CONNECT_MODULE_TO_SHELL of handleNotification funciton, this line

var shellOut:IPipeFitting = junction.retrievePipe(JunctionMediator.STDIN) as IPipeFitting;
should be

var shellOut:IPipeFitting = junction.retrievePipe(JunctionMediator.STDOUT) as IPipeFitting;

Good eye there, swidnikk!

The only reason this didn't choke is that the Shell never talks to the Prattler module. If you note, the PrattlerJunctionMediator's handlePipeMessage method is currently not doing anything. The PrattlerModule sends its FeedWindow on its STDSHELL output pipe to the Shell when it is created.

-=Cliff>

Thanks :)

I must say that the pipes utility is damn cool. I ported some of the ideas from your demo to my application and everyone on my team is very happy with it. We had a few meetings to discuss the pipe messages each core handles and now we're happily on our way implementing again. What I really like is the flexibility and freedom this utility gives. It also helps to fight feature/code bloat. Instead of piling up functionality in a single project, we have several smaller ones that are dedicated to a specific task. We currently have 5 cores including the shell.

While I did go ahead and create a teesplit pipe from the shell to all cores so that general messages can be broadcast, I found it useful to have a dedicated pipe from the shell to each core. Each core has only a STDSHELL pipe for outbound communication so, the shell's junction mediator performs all the message switching.

Hi Folks,

Please note, the PipeWorks demo has changed and so has the Pipes Utility. The IPipeAware interface and JunctionMediator have been refactored into the utility itself.

-=Cliff>

Hi...Just getting started with Flex and PureMVS. THis looks like a great demo. Im having a small problem maybe you can point me in the right direction. Ive added both the pipeworks folder and the Muticore swcs' to the library path, but I get 2 compile errors below on the Facade. Line 30. I thought it would be the library, but its there. Any ideas? Thanks Bob
       
private var facade:ApplicationFacade = ApplicationFacade.getInstance(NAME);

Severity and Description   Path   Resource   Location   Creation Time   Id
1046: Type was not found or was not a compile-time constant: ApplicationFacade.   Pipeworks/src   Pipeworks.mxml   line 30   1215628662177   29
Severity and Description   Path   Resource   Location   Creation Time   Id
1120: Access of undefined property ApplicationFacade.   Pipeworks/src   Pipeworks.mxml   line 30   1215628662177   30

Is the src folder the folder in the build path, or is it the PipeWorks project folder? It should be the src folder.
-=Cliff>

Hi Cliff,

I saw the Modularity demo that you have authored. It is very impressive. [http://svn.puremvc.org/Demo_AS3_MultiCore_Flex_Modularity/]

If the application is a very complex one, the app size (swf) will become extremely huge even though it is modular right? What are the ways to alleviate this problem?

Is it not a good idea to generate multiple swf's, one swf per module and load them when required realtime? :-\
I got this idea from http://www.websector.de/blog/2008/06/21/a-basic-puremvc-multicore-as3-example-using-pipes-utility-and-modules/ (http://www.websector.de/blog/2008/06/21/a-basic-puremvc-multicore-as3-example-using-pipes-utility-and-modules/)

I am keenly waiting to receive your valuable inputs on this.

Thank you.

Yes of course, you want the modules to be compiled and loaded in almost any case, but that was beyond the scope of the demos which were focusing on the collaborations between modules.

Soon I will introduce a loader utility.

-=Cliff>

Hi Cliff,

I have a doubt with the PipeWorks demo.

In "PrattlerModule.as", you are getting an instance of the ApplicationFacade with the key as "moduleID" which is an incrementing key.

So each time I click on the "New Prattler" button, a new ApplicationFacade  is instantiated with a unique moduleID. Now, when I close a prattler window, the mediators are being removed. What about the facade? Is it not a good idea to remove the facade as well since I feel this is a memory leak? Am I correct?   :-\

Regards,
Ramanuja

Yes, and the module should be disconnected from the logger and shell pipes as well. A facade.removeCore(key) is what's needed once all references in the main app have been removed.

I'll make these changes to the demo as soon as possible.

-=Cliff>

Cliff,

Thanks for the quick response  :)

Regards,
Ramanuja

ello,

I'm currently writing up a Pipes tutorial to force myself to understand it. I've found that writing about something makes me understand it far more than simply skimming over some docs etc.

Anyway, I'm wondering if there are any resources anywhere talking more about Queues and Filters. The only info I've found so far is within the source code of the Pipes demo. Anyone know if there's any more information floating around about either of them?

Cheers,
toby

Hi Toby,

Filters and Queues are a pretty useful concept. Right now, aside from the demo code, you'll probably want to start by reading the Pipes API Docs carefully for these classes, then scoping out the Pipes Utility Unit Tests. Each component is considered there with its own set of tests, so you can see a Queue or a Filter actually working in the wild without a huge supporting application all around it.

Briefly, you put them into a pipeline and send messages to control their operation. Those control messages are consumed by the Filter or Queue and not passed on down the pipe.

-=Cliff>

Thanks for the advice Cliff... I'll take a peek over the weekend and post a link to whatever I end up writing here :o)

Just wanted to say that the best piece of advice here was to look into the Unit Tests. I've never actually looked at any Unit Test code before, and always avoided using it in my apps (as ever, mistakenly believing it was more complicated than it is). Not only have these classes helped me work out what's going on with Queues and Filters, but I've also learnt a lot about Unit Testing. Nice one Cliff!

Hi All,
sorry just got into Pipes Utility - do I get it right to print out the plumbing scheme for PipeWorks like follows?
thanks so much for your help
francesco

(http://www.scansani.org/data/pipeworks-plumbing-schema.png)

That looks about right.

-=Cliff>