-
-
SEARCH
Accueil - Flex modules with PureMVC pipes simple demo
Last modified :
Flex modules with PureMVC pipes simple demo
I worked on this project earlier this year, and I never found time to publish it. But since a month or two, I see that many questions arise on blogs and forums about PureMVC Pipes utility. I think that we need more examples of simple implementation of this utility. That is why I have added an example to the list for those whom wish to have a good start with this utility.
I've made this project for myself to understand the basic of Pipes. My needs were primarily to allow some modules to communicate among them, something that none of the examples I tested show.
You can view a live demo of the project, it has been published with ViewSource activated (on right-click menu).
The project is therefore as simple as possible and well documented. Its purpose is to:
- Add and load Flex modules (real modules loaded as files)
- Remove the module and all its connections to make it ready for Garbage Collection
- A module can send messages to all other modules
- A module can send messages only to one type of module (using Pipes Filters)
- A module can send messages to the shell
- A module can receive messages from the shell
The main problem on this project was to let module communicate among them. If you follow the guidelines of the Pipe utility, you get to do something where each plug-ins has a TeeSplit and TeeMerge connected to all other plug-ins. This can be done in a very simple and beautiful way with a simple 20 lines ModuleMediator. But with many modules it tends to became heavy at runtime (mainly memory consumption) and prevents to correctly remove outputPipes from a module to another when removing a module (ask me if you want more details).
I therefore chose to create a ModuleJunctionMediator dedicated to connect all the modules between them. This ModuleJunctionMediator is very simple, it can connect each new module with a TeeMerge and a TeeSplit. As it maintains a reference to a unique Junction instance, it can properly disconnect any module with Junction.disconnectFitting when needed. It's last but main role is to forward any message from a module to all others.
I tried several solutions before using this one. I think we can do much better. I do not even talk to use Fabrication which have probably make all this easier, because it was not the purpose of this example.
You can launch the live demo, download or browse the sources.
v1.2 - Applied some refactoring to handle generic modules instead of specialized HelloModule. The project now use an IModule interface instead of the previous IHelloModule. The HelloModuleMediator, LoadHelloModuleCommand, UnloadHelloModuleCommand of the shell are respectively named ModuleMediator, LoadModuleCommand, UnloadModuleCommand.
v1.1 - I have updated the project to add a ModuleLoaderMediator in the Shell to better handle HelloModules loading and unloading.
The current version is now PureMVC_FlexModulesAndPipes_v1.2
Comments
>I implemented IEventDispatcher in the module proxy so it can dispatch an event
>when it is updated. I passed the module facade to each module on instantiation
>so each module retrieves its proxy and then attaches a listener to it.
Sorry Greg, but this implementation doesn’t seem to be a good idea for me. It breaks the MVC and PureMVC paradigm. First, Proxy class in PureMVC are already able to send notifications with the *sendNotification* method. Next, when you give the Facade instance of a module to another, you give too much knowledge to the second module. Pipes are there to do this work and hide the module implementation from another.
I understand what you’ve done. While converting the Flex examples to Flash you wanted to simplify the way modules were managed in pure ActionScript, because module doesn’t exist in pure ActionScript. But you can’t do it this way. You better have to use the official Pipes implementation to let modules communicate, not EventDispatcher. It’s a little more code, a little more complicated, but it guarantee the quality of your implementation.
What I understand here, is that we need a multicore application plus Pipes example of use in pure ActionScript. I will try to work on it.
Hello again, I wanted to explain or clarify a few things.
First Your example proxy is inherently capable of the function I created because it uses ArrayCollection which does exactly what I did by extending ListCollectionView which implements ICollectionView that extends IEventDispatcher…
inside your module…
messages.addEventListener(CollectionEvent.COLLECTION_CHANGE
Second I only pass the module it’s own facade and as I see your modules also have their facade as they call facade = HelloModuleFacade.getInstance( moduleID );
inside my module…
public function Module(facade:IFacade) {
this.facade = facade;
this.proxy = facade.retrieveProxy(ModuleCommunicationProxy.NAME) as ModuleCommunicationProxy;
this.proxy.addEventListener(ModuleCommunicationProxy.GET_COMMUNIQUE, handleChange);
The only real difference is that your module mediator listens for a list of all possible Flash events inside the module and in mine the module sends notifications directly to it’s junction mediator but I suppose it could do it by way of the module mediator. I believe your module could do the same though since it has reference to it’s facade. Thank you for the retrospective though, It is always good to have someone question my methods.
>The only real difference is that your module mediator listens for a list of all possible
>Flash events inside the module and in mine the module sends notifications directly
>to it’s junction mediator
Ok, first time I understand that you were passing the reference of a module Facade to another. And it seems that you are not using EventDispatcher to connect modules. To be honest, I really have a hard time to understand with only a description of the application. 
I will try to convert my example to a “pure ActionScript” example at the end of the week.
Hi Tek,
thank you for a very interesting and useful example.
I can’t make sense of one detail so far. On each “AddHelloModule” operation two instances of HelloModuleMediator are created - the first is created by the shell (in AddHelloModuleCommand) and the second is created by hellomodule itself (in StartupCommand). Can you please clarify the reason for that?
Hi Luiz,
the two classes have the same name but different roles. Naming it the same is probably a bad idea. The Mediator owned by Shell could simply be called ModuleMediator now that I modified the project to make the module loading more generic. I will look into the project to modify it.
So, currently the HelloModuleMediator owned by the shell is intended to instruct the module to setup/teardown each module without any other knowledge of the module than its current IHelloModule interface. And the HelloModuleMediator is much more as any PureMVC mediator you already know, and is only used to handle the module user interface of the module itself (user interaction, events, display, etc…)
Thanks to point me this, I will modify it asap.
Thanks! Now that you mentioned it I found those two different classes in two locations. All in all your example is an exciting reading. I guess adding a second type of module ( in addition to HelloModule) would make the example even more generic.
Thanks a lot for sharing your ideas and actual implementation!
Luiz, you can now find the updated version reflecting changes we talk about and a changelog in the update section of the blog post.
I also like this idea of adding several module type, but I prefered not to add complexity to the project as this is a simple demo.
Tek,
I really appreciate your efforts to make all the refactoring so fast.
Luiz
Please convert the source code using Fabrication
Safrizal, sorry, but I’ve not planned to convert this demo to Fabrication. I’ve planned some other updates regarding the way HelloModule communicate with pipes but not this one.
Hi Tek, thank you. I used your example and the Piping the Machine example @ http://joelhooks.com/ as the basis for an Actionscript only project. I implemented IEventDispatcher in the module proxy so it can dispatch an event when it is updated. I passed the module facade to each module on instantiation so each module retrieves its proxy and then attaches a listener to it. This also allows the module to directly notify its junction mediator. Each module is assigned to an index in the proxy array. This acts as a data binding to the proxy, something not readily available in Actionscript only projects. Module to module communication is then bounced off the shell back to the intended module. No listeners are needed in the module mediator only one listener inside each module attached to its proxy. I also modified the module message header to contain a to-module and a from-module parameter. When the module proxy gets an update it uses the to-module parameter as the index in it’s array. As mentioned prior each module listens to its index in the proxy. As a side benefit each module can also access another modules data if needed and I suppose an index in the proxy could be assigned to the shell so that data would be readily available too. Thank you again for your great example.