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: Two PureMVC modules in same app  (Read 7954 times)
worthyashes
Newbie
*
Posts: 1


View Profile Email
« on: June 16, 2008, 01:01:47 »

Hi all,

I'm learning PureMVC at the moment and it has coincieded with a need I have for a debugging application.  Basically I was to create a little widget that I'll compile to an swc so I can drop it on my projects for debugging.  As I'm learning PureMVC I thought this would be a good test for me to create something working.  However then I thought if I use a PureMVC based widget to debug a pureMVC application then as the Model, facade and controller are singletons then I'm going to have problems with the widget and the main application potentially having naming conflicts for commands, variables etc.  As I'm not the only developer and this widget may be used across the team I can't guarantee that the same names won't be used.

So my question is this - is it possible to have 2 instances of the PureMVC framework living alongside one another in the same app?

Thanks,

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



View Profile WWW Email
« Reply #1 on: June 16, 2008, 07:55:49 »

Yes, the answer is MultiCore.

The MultiCore version of the framework uses Multitons instead of Singletons, allowing multiple, isolated PureMVC 'Cores' running in the same VM without namespace conflict.

In fact, if you have a look at the new PipeWorks demo for MultiCore, you'll find a LoggerModule which may be close to what you're after for debugging. I'm planning to extract that LoggerModule into a separate utility project.

Pipes, by the way is the way these 'Cores' talk to each other, and PipeWorks is a demo that illustrates its use with the MultiCore version of the framework.

-=Cliff>
Logged
justinlevi
Newbie
*
Posts: 1


View Profile Email
« Reply #2 on: June 19, 2008, 03:05:46 »

Cliff,

Along these lines, if I were to create a reusable component swc with multicore, where would be the appropriate place to put the public API methods?

As an example, let's say for instance that I want to create a reusable slideshow component that should expose methods like, back(), next(), load(), etc...  I don't want the user to have to access these methods through the "image" view. This seems cumbersome to me to expect a user to import a view class and call a method like next() exposed in a package like com.useflexmore.view.image.

I'm probably missing something obvious and I apologize if this is a silly question, but just placing a public method on my Slideshow class (Facade) called "next" which would then in turn communicate with a command seems inappropriate to me somehow.

I'm interested in the best approach to creating reusable Flex components with PureMVC that expose a public API which still follows the design model. All the examples I've looked at so far tend to focus on implementing PureMVC in a complete application.

I'm coming from a few years of Cairngorm experience and am finally getting around to trying out PureMVC on a project.

Best regards,
Justin Winter
useflashmore.com
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: June 20, 2008, 05:11:59 »

If you're wanting to expose a Public API for the Module, then you'll want to look at the Modularity demo.

There are essentially 2 approaches to handling Modules in MultiCore:

Interfaces - the app and/or the module expose interfaces for the methods that can be called from eac other.

OR

Pipes - Module and app have pipes constructed beteen them and they send messages to each other.

So your API is interfaces if the two Cores are to be given references to each other and pipes if not.

The interface proposition is less safe than pipes obviously. Third party code could do unsavory stuff, so controlling the references it is given to thind in the running app is important.

-=Cliff>
Logged
Pages: [1]
Print