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 [2] 3 4 5
Print
Author Topic: Pipes - A PureMVC AS3 MultiCore Utility  (Read 93259 times)
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #15 on: May 30, 2008, 10:48:47 »

Yes, it is meant to be used by any core to talk to any other core. Shell to module or module to module, they're all 'cores' to PureMVC.

As to Proxies handling the junction, we must be able to send and receive messages and act in a mediation role betweeen the junction and the rest of the app. So a Mediator is more appropriate than a Proxy even if the module we send messages to is a 'database' module.

Have a look now at the PipeWorks MultiCore demo just posted.

-=Cliff>   
Logged
mikebritton
Full Member
***
Posts: 42


View Profile Email
« Reply #16 on: June 01, 2008, 12:14:49 »

I see in the demo that mx.modules.ModuleBase is used in the PipeAwareModule.  I assume extending MovieClip would be OK for Flash AS3 modular apps?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #17 on: June 01, 2008, 05:21:02 »

Consider the Main App/Shell a core as well. And pipes connect all sorts of Cores in whatever configuration is necessary. See in the PipeWorks demo how the LoggerModule, the PrattlerModule and the Shell all have JunctionMediator subclasses that let them communicate with everything else.

Of course to connect two sibling modules without them having a reference to each other (thus defeating the point), a 'higher power' which has a reference to them both. this means the Shell will probably coordinate the activity of connecting the pipes from itself to various modules and between various modules.

-=Cliff>
Logged
mikebritton
Full Member
***
Posts: 42


View Profile Email
« Reply #18 on: June 01, 2008, 07:14:29 »

I get the idea of a shell being on the same level as any other core, etc, and managing messages between cores, but specifically in the case of PipeAwareModule (org.puremvc.as3.multicore.demos.flex.pipeworks.common) -- I assume there's nothing tying this to the use of mx.modules.* -- that is, I can have my PipeAwareModule extend MovieClip instead of Module, right?

I suppose my overall question is can I do the same thing in without Flex or the Flex framework?  This will be an important distinction for those of us using Flash only.  In my case, I need to be sure this is the reality before I move forward with a really large codebase using Pipes.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #19 on: June 01, 2008, 07:28:50 »

Sorry about that last post looking like I wasn't listening to you. I was on my cell phone and didn't see it was on an extra 'page' of the thread.

You can totally do the PipeAwareModule thing without using mx.* Use MovieClip if you want, not a problem.

I based PipeAwareModule in the demo on ModuleBase because I'm working on a job using them and I wanted to make sure that the use of the framework, the pipes utility and Flex Modules were all demonstrated to work properly together.

I'm going to have to noodle a bit on how to pull some of the stuff in that demo out into utiilites in their own right.

-=Cliff>
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #20 on: June 04, 2008, 10:15:43 »

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>
Logged
swidnikk
Courseware Beta
Jr. Member
***
Posts: 13


View Profile Email
« Reply #21 on: June 05, 2008, 03:50:52 »

One thing I've been noodling about is how to deal with the complexity of managing the message types between cores as the number of specialized cores increases. I currently have 6 cores which are loaded depending upon the privileges of the user.

First we created a class that extends the Message class for each core. However, some cores need to turn around and send a response message, which means that the junction mediator of each core would have to know about several message classes and this quickly got confusing. Instead we're making heavy use of a class that also extends the Message and adds a destination to the header. The destination is also used as the name of dediated core  pipes.

Some of the cores connect to asynchronous web services and when a result is returned in response to query message, we can either send the result with the query response or just notify that data arrived and then implement a robust API for each core.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #22 on: June 05, 2008, 07:10:16 »

Sounds like you're getting the hang of it. Thanks for reporting in with these sort of thoughts.

The MultiCore+Pipes environment is really powerful, but but you really have some multi-level architecture considerations now. And the sooner the patterns and anti-patterns are uncovered the better!

-=Cliff>
Logged
lukesh
Newbie
*
Posts: 4


View Profile Email
« Reply #23 on: August 27, 2008, 12:36:24 »

My context is a multi-module application, and instead of removing modules, I cache them and simply add or remove them from the display hierarchy. I never unload the PMVC cores.

IPipeAware modules have accept* methods but not corresponding remove* methods. When a module is unloaded, I would like to remove the plumbing. I understand that I could just leave the plumbing active and test whether or not it should receive messages, but I would have preferred to remove and re-add plumbing as needed.

I tried re-adding plumbing when a module was activated, which didn't error, but when I attempted to send a message the Pipe class RTE'd with a null output. It seems like there should be a clean way to remove any plumbing associated with a loaded module. I also feel like I may be overlooking something, or mis-implementing Pipes altogether.

I have what I feel to be a very clean and vanilla implementation of MultiCore and Pipes otherwise, and I'd love to release it to the community as a demo. Cliff, what is the best way to get this to you for your review? I think many could benefit from this.
Logged
lukesh
Newbie
*
Posts: 4


View Profile Email
« Reply #24 on: August 27, 2008, 12:41:11 »

...another thing that I felt was appropriate was using a ModuleProxy in the main application, versus storing modules in a Mediator, which it seems that every other demo does. In reality, loaded modules are part of the model, and their interaction with the user (that is, being added to the display hierarchy) alone is a view element. I'd love to get some feedback on this.

Also, I've included the app structure below which gives you the basic idea of what I'm trying to accomplish:

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



View Profile WWW Email
« Reply #25 on: August 27, 2008, 01:15:55 »

Modules are typically used to compose the UI. How does one construe that as having something to do with the Model? Just because they may be loaded dynamically doesn't make them a part of the domain model.

Even if the module extends ModuleBase and is not directly addable to the display hierarchy, but creates and exports components that will, it is still a View tier object.

-=Cliff>   
Logged
lukesh
Newbie
*
Posts: 4


View Profile Email
« Reply #26 on: August 27, 2008, 01:31:07 »

Cliff, I see the point you are making, however my rationale was:

1. Modules do not necessarily need to be part of the display hierarchy, interact with the user, or create and export visual components (i.e. the view).

2. The list of loaded modules can be articulated in different ways in the view tier. For example, let's say that I had a module container that displayed the actual module, and another control that showed a button for each loaded module (both view components, both with their own Mediators). The ModuleProxy maintains an array of loaded modules and sends notifications indicating that the module is loaded and ready. Any Mediator observing can then articulate that as they need to, either by actually adding the module to the display hierarchy, or by simply creating a button.

Does this make sense?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #27 on: August 27, 2008, 04:49:25 »

I too have Adapter modules that do nothing but talk to services. But most modules end up composing the UI so I consider them marginally more apropos to the View tier. Its hard to think of a swf file as data. It is application code. The Model tier is about representing the domain - the data the system manipulates.

Plus, since mediators can listen for notifications it cuts down on commands.
 
-=Cliff>
Logged
lukesh
Newbie
*
Posts: 4


View Profile Email
« Reply #28 on: August 27, 2008, 04:55:11 »

Actually, then would you recommend architecting the system with as few commands as possible? My biggest issue with PMVC is that notifications can be handled in more than once place / methodology, and it seems to make app logic harder to follow. Not sure if you got my PM, but the sample app is here:

http://lukesh.com/files/AdeptivPMVC.zip

I'd really appreciate feedback.

I love that PMVC is so flexible, language agnostic, etc... but sometimes it feels like it gives you more rope than you need, and definitely enough to hang yourself with. I'm just trying to get a decent meta-meta-framework :) that will guide our development team for backend-y Flex apps.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #29 on: August 27, 2008, 07:42:13 »

I'll get a look at this as soon as possible. I'll be travelling tommorow and may not get the chance until I return late next week.

-=Cliff>
Logged
Pages: 1 [2] 3 4 5
Print