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
1  PureMVC Manifold / MultiCore Version / Re: Have you seen the pipes version demo which use dynamic module? on: August 18, 2008, 01:25:45
Sorry, about that, I am planning on posting the full source after refactoring to clean it up.

2  PureMVC Manifold / MultiCore Version / Re: Pipes Utility - Disconnecting Pipes on: August 01, 2008, 08:51:21
The approach I took was to have the module 'cache' the fittings when connecting them.

public function cacheFitting(localFitting:IPipeFitting,remoteFitting:IPipeFitting):void

Then, when it comes time to unload a loaded module, I simply 'cleanup'

public function cleanup():void
while(cachedFittings.length > 0)
var localFitting:IPipeFitting = cachedFittings[cachedFittings.length-1].local;
var remoteFitting:IPipeFitting = cachedFittings[cachedFittings.length-1].remote;

if(remoteFitting is DynamicTeeSplit)
   (remoteFitting as DynamicTeeSplit).disconnectFitting(localFitting);


Hope that helps!!!
3  PureMVC Manifold / MultiCore Version / Re: Having a Hard Time with Pipes on: June 17, 2008, 09:41:35
Thanks, glad the diagrams helped (a picture is worth 1024 words :) ). 

I went ahead and posted the 'pipes' version of the mortgage app.


I apologize for all the linking!!
4  PureMVC Manifold / MultiCore Version / Re: Having a Hard Time with Pipes on: June 16, 2008, 10:19:02

The first diagram (that Mike posted above) was pertaining to an implementation that allows an application to load modules that, in turn, load modules (a parent, child, grandchild implementation).  Probably can [should] be safely ignored for anyone just getting their feet wet [pun??] in pipes.

Thanks again for this great utility Cliff!!

BTW, I'm happy to report it's [the Pipes utility] working *great* in the enterprise app(s) I'm working on.
5  PureMVC Manifold / MultiCore Version / Re: Having a Hard Time with Pipes on: June 15, 2008, 08:10:28
You can get info on that diagram, in context, at http://www.joshuaostrom.com/2008/06/13/pipe-architecture/

Regarding an overview of using pipe's I posted at

This diagram would probably be better for those trying to conceptualize the architecture.  The diagram illustrates an app that loads two 'child' modules.

Hope that helps!!!

6  PureMVC Manifold / MultiCore Version / Re: Pipes Utility - Disconnecting Pipes on: June 13, 2008, 08:03:07
No problem.  I've posted an architectural diagram over at http://joshuaostrom.com to help anyone working with the Pipes Utility.

7  PureMVC Manifold / MultiCore Version / Pipes Utility - Disconnecting Pipes on: June 11, 2008, 01:20:33
I refactored the MortgageApp to use the pipes utility.  I like the approach the Pipes utility takes - build the module-app app-module integration on top of the exisiting modules (i.e. add a junction  mediator to your exisiting module and ensure your module implements IPipeAware).

Cool stuff Cliff.

I did run into a question however.  I'm finding the need to disconnect individual 'pipes' from a TeeSplit or TeeMerge - not simply 'all' pipes. 

For example, my 'shell app' has an outbound (TeeSplit) and inbound (TeeMerge) pipe.  Dynamically loaded modules create pipes and connect to the latter 'shell' pipes.

When it comes time to unload a dynamically loaded module, I currently don't have a way to remove to the connection to the app's TeeSplit / TeeMerge without disconnecting all of the other modules' pipes as well. 

I simply subclassed TeeSplit and added function to disconnect the passed fitting. 

public function disconnectFitting(output:IPipeFitting):IPipeFitting
Doing so solved my problem.

*If* I'm not missing something, it might be worthwhile to add the latter function to TeeSplit.

8  PureMVC Manifold / MultiCore Version / Re: "Fully" Encapsulated Dynamic Modules on: May 23, 2008, 10:47:35
  I've posted a [quick] AS3 demo as well http://dluminosity.com/blog/2008/05/24/as3-puremvc-dynamic-modules/ for those interested.

9  PureMVC Manifold / MultiCore Version / Re: Pure AS3 Demo with External Modules on: May 23, 2008, 10:45:11
  I've posted a quick demo at http://dluminosity.com/blog/2008/05/24/as3-puremvc-dynamic-modules/.

  I didn't take the time to build a menu system.

 It's one possible approach, keep an eye on the Pipes utility Cliff is working on :)

10  PureMVC Manifold / Demos and Utils / Re: Pipes - A PureMVC AS3 MultiCore Utility on: May 19, 2008, 07:54:18
Exciting stuff Cliff, THANKS!!  It's always great to see a knowledgeable architect at work ;)

11  PureMVC Manifold / MultiCore Version / Re: Minor View change *suggestion* on: May 19, 2008, 11:25:04
Yes, I settled on inbound / outbound notification mappings being defined statically.  This turned out to be a better approach.

thanks again!!

12  PureMVC Manifold / MultiCore Version / Demo posted on: May 19, 2008, 10:20:16
 I've posted a working demo at http://dluminosity.com/blog/2008/05/19/dynamic-flex-modules-with-puremvc/

The application->module, module->application 'bridge' resides in a function added to the module's facade...

 override public function initializeMappings():void
    outboundMappings:Array = new Array();
    outboundMappings[QUOTE_GENERATED] = EventNames.LOAN_QUOTE_READY;

    inboundMappings = new Array();
    inboundMappings[EventNames.REQUEST_FOR_LOAN] = QUOTE_REQUESTED;

The module will 'subscribe' to any notifications in 'inboundMappings.'

13  PureMVC Manifold / MultiCore Version / Re: Minor View change *suggestion* on: May 19, 2008, 09:35:57
  I should have let the dust settle before posting.  Please disregard the request :)

(This was to support the change in a dynamically loaded modules "notification Interests" over time - I've settled for a much cleaner approach).

14  PureMVC Manifold / MultiCore Version / Minor View change *suggestion* on: May 17, 2008, 06:57:43
I've been cleaning up my code (hoping to post it soon) on dynamically loaded modules. 

First off, I realize the View can be sub-classed easily - this is just a suggestion to avoid the need of doing so.

I came across the following function in the View class


public function removeObserver( notificationName:String, notifyContext:Object ):void
// the observer list for the notification under inspection
var observers:Array = observerMap[ notificationName ] as Array;

// find the observer for the notifyContext
for ( var i:int=0; i<observers.length; i++ )
if ( Observer(observers[i]).compareNotifyContext( notifyContext ) == true ) {
// there can only be one Observer for a given notifyContext
// in any given Observer list, so remove it and break

// Also, when a Notification's Observer list length falls to
// zero, delete the notification key from the observer map
if ( observers.length == 0 ) {
delete observerMap[ notificationName ];

This works great when the mediator has a static lists of interests.  However when that list is dynamic some problems can arise. 

My request is for the addition of a simple check that

var observers:Array = observerMap[ notificationName ] as Array;

didn't return null...



What do you think?
15  PureMVC Manifold / MultiCore Version / Re: "Fully" Encapsulated Dynamic Modules on: May 14, 2008, 06:45:55
Thanks for the reply!!

I glad to say I've got it working :)
With a few changes to my original 'brain storm.'  Here's what I ended up with...

My modules communicate w/each other and the parent app.  Likewise the parent app communicates w/each module.  The parent app has NO IDEA what modules will be loaded or how many.  The modules are loaded / unloaded dynamically at runtime.  This provides me with the scalability I was shooting for - my parent app doesn't have to be re-compiled for every 'nth module I write.

I'm staying fairly well encapsulated as well - my modules don't reference the parent app, it's facade or anything like that. 

Pages: [1] 2