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: Is MultiCore necessary for use of Flex Modules?  (Read 9891 times)
webkuh
Newbie
*
Posts: 2


View Profile Email
« on: April 16, 2008, 01:00:35 »

Hi

I've used the standard AS3 PureMVC framework for a few projects now but am just starting another project now where I want to make use of Flex modules to be able to divide up my code/components into a load only when required basis. Also I might want to make some modules available to some users but not others.

I want my Flex modules that get loaded into the application to each be controlled by a single mediator - again the mediator code should only get loaded in with the module.

This is one of the benefits I understood the multiicore version of PureMVC would offer.

In the modularity demo I can see that each module/widget has it's own ApplicationFacade. This isn't necessary for my project, I just want to be able to hook in loaded modules into the PureMVC app and to be able to listen and send notifications from/to the main app and then be unloaded if necessary.

I've managed to achieve this by setting my module(s) to implement a custom interface - IPureMVCModule (which extends IUIComponent). When the module's creation complete event is triggered it then adds it's self to the main application like this:

:
<?xml version="1.0" encoding="utf-8"?>
<mx:Module xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" visible="false"
implements="net.editioninteractive.modules.interfaces.IPureMVCModule"
  creationComplete="facade.loadModule(new ModuleDTO(this,ModuleViewMediator))" >
<mx:Script>
<![CDATA[
import net.app.player.view.modules.ModuleViewMediator;
import net.app.player.model.vo.ModuleDTO;
import net.app.player.ApplicationFacade;
public static const NAME:String = 'MainApp';
protected var facade:ApplicationFacade = ApplicationFacade.getInstance( NAME );
]]>
</mx:Script>


<mx:Panel title="My Panel" width="100%" height="100%" />
</mx:Module>

Where 'MainApp' is the key of the already loaded ApplicationFacade.

Inside the main ApplicationFacade my custome loadModule method looks like this:

:
        public function loadModule( data:ModuleDTO ):void
        {
       
        sendNotification( MODULE_INIT, data );
        }

Where MODULE_INIT is mapped to a command that registers a new instance of the mediator class with the new module as the viewComponent, passed through in the custom ModuleDTO dto.

This works - so I'm pleased about that.

The main reason for my post is for 2 reasons:

1) Would my use of PureMVC above be considered good/bad practice?

2) I could achieve the above with the standard PureMVC framework in a similar way couldn't I? Ie, MultiCore isn't necessary for use of PureMVC with modules?

Thanks for the help and the framework - really enjoy working in this way once I got to grips with it!

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



View Profile WWW Email
« Reply #1 on: April 16, 2008, 05:54:58 »

Hi,

The short answer is no you don't need MultiCore if you want your entire loaded module to be treated as a single view component with a single mediator for it. You can easily get by with the Standard version and a scheme for loading and unloading.

And no, your use of MultiCore would not be the recommended way of doing it.

The reason for MultiCore is so that an entire set of the Core actors can run in the same VM with another one, (possibly written by a different vendor without coordination) without having collisions in Notification namespace. These Cores are isolated and do not communicate via notifications sent through a shared Facade for this reason.

The concept of modular programming takes the encapsulation to the extremes. Just how loosely-coupled can you get? Programming to interfaces is the best way to achieve loose coupling. And so interfaces are the language construct used to enforce communication between Cores.

The MultiCore demo creates an interface called IWidget that the W1idgetShell in the main app uses to communicate with any Widget. It also creates an interface called IWidgetShell which the Witget uses to communicate with the WidgetShell. That's it. No need to come up with a scheme to be sure notification names are unique inside the two Cores, they call interface methods.

-=Cliff>
Logged
webkuh
Newbie
*
Posts: 2


View Profile Email
« Reply #2 on: April 17, 2008, 02:12:39 »

Hi Cliff

Thanks for the reply.

And no, your use of MultiCore would not be the recommended way of doing it.

So using the same approach but with Standard framework would be suitable? If my implementation of a loadModule method into the facade is not a good idea can you offer an alternative suggestion?

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



View Profile WWW Email
« Reply #3 on: April 17, 2008, 12:18:15 »

That your implementation under the MultiCore Version of the framework was not appropriate does not mean it would not be appropriate under the Standard Version.

The difference lies in the communications between the loaded module or swf and the surrounding app. Under MultiCore it would not be a good practice to share a Facade between the main app and the loaded module. This is because the entire point of MultiCore is to allow multiple isolated cores to run in the same VM. Their communications is not via shared Notifications but by programming to interfaces.

Under the Standard Version, however, if you want to load a module or swf and have its Mediator reside in the application's single Core, there is nothing to preclude this. How you load the modules is up to you. I understand how you're doing it with the method on the ApplicationFacade, but what is calling this method? I'd probably instead have some event from the UI handled by a Mediator that sends this Notification.

Cluttering the Facade with extra methods should be avoided if possible. If called from the UI, it makes the UI components need to know more about the ApplicationFacade. If called from actors within the system, a better answer is almost always a Notification triggering business logic.

-=Cliff>
Logged
Pages: [1]
Print