Cliff, if you'd like to check out FlexJS+PureMVC by yourself, it's pretty easy:

1) Download and install the FlexJS SDK and setup your favorite IDE [1]
    (It's recommended to install the nightly build, bugs are expected!)
2) Create a FlexJS example project. Take a look at [2] to get an idea of the basic FlexJS app structure.
    (The "model" and "controller" beads are optional)
3) Copy your awesome PureMVC AS3 lib source to your example project (or use the swc from previous link)
4) Implement your PureMVC actors as you are used to
5) Your InitialView of your example project could look like this:

:

<js:View xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:js="library://ns.apache.org/flexjs/basic"
width="100%" height="100%"
initComplete="onInitComplete()">
<fx:Script>
<![CDATA[
import core.as3.ApplicationFacade;

public var facade:ApplicationFacade  = ApplicationFacade.getInstance("MySuperCore");

private function onInitComplete():void {
facade.startup(this);
}
]]>
</fx:Script>

<js:Group width="800" height="600">
          ...
</js:Group>

</js:View>

6) Compile your project
    (The compiler creates a Flash version and a JS/HTML5 version)
7) Done, hope it works well ;-)

Some hints if you would like to port Flex code to FlexJS:
You have to remove all flex/flash dependencies from your AS3 code and you have to replace your mx/spark components by FlexJS components.
Remember the popular Flex ArrayCollection (mx.collections.ArrayCollection) is also part of the Flex framework and has to be replaced by e.g. the FlexJS ArrayList.
The FlexJS component sets are not yet as rich as Flex mx/spark but FlexJS makes great progress.
Thanks to some smart guys FlexJS has captured the MaterialLight lib [3] which is available in the nightly build.
This could also be helpful [4].

HTH,
Olaf

[1] https://cwiki.apache.org/confluence/display/FLEX/Getting+Started+With+FlexJS
[2] https://cwiki.apache.org/confluence/display/FLEX/Application+Structure
[3] https://getmdl.io/started/
[4] https://nextgenactionscript.com/

This is the related "Flex Users List" thread:
http://apache-flex-users.2333346.n4.nabble.com/FlexJS-PureMVC-with-FlexJS-td14880.html

I've started to port the EmployeeAdmin demo to FlexJS a while ago, hope I'll have some free cycles and can pull myself to finish it soon ;-)

Olaf

Hi Cliff,
I've already outsourced my model for a long time but it never occurs to me to just introduce a static class var inside the proxy.
So, many thanks again for your support!

Cause this is probably a common use case I'd like to share the code:

:

public class LoginProxy extends Proxy
{
public static const NAME:String = "LoginProxy";

        // This could also be a VO of course
protected static var sharedAuthToken:String;

public function LoginProxy(proxyName:String=null, data:LoginVO=null) {
super(proxyName, data);
}

protected function setAuthToken(value:String):void {
LoginProxy.sharedAuthToken = value;
}

public function get authToken():String{
return LoginProxy.sharedAuthToken;
}
      
        ...
}

Thanks,
Olaf

Hi,
this might be also already discussed in the past so sorry for asking again ;-)

In a lot of cases it's necessary to share e.g. login information across all cores.
I wonder if it's better to share a LoginProxy instance that resides in the shell or if it's better to share the LoginProxy class,
let each core create its own instance and just inject the LoginProxy data to the new instance.

[1] Share instance:
// Retrieve login proxy from shell and access login data directly
var shell:IFacade = Facade.getInstance(SharedConstants.SHELL);
var loginProxy:LoginProxy= shell.retrieveProxy(LoginProxy.NAME) as LoginProxy;

:

// Retrieve login proxy from shell and access login data directly
var shell:IFacade = Facade.getInstance(SharedConstants.SHELL);
var loginProxy:IProxy= shell.retrieveProxy(SharedConstants.LOGIN_PROXY) as IProxy;
var loginVO:LoginVO = loginProxy.getData() as LoginVO;


[2] Share class:

:

// Retrieve login proxy from shell, register new login proxy instance within this core and inject loginVO
var shell:IFacade = Facade.getInstance(SharedConstants.SHELL);
var loginProxy:LoginProxy = new LoginProxy(LoginProxy.NAME, shell.retrieveProxy(LoginProxy.NAME).getData() as LoginVO)
facade.registerProxy(loginProxy);
var loginVO:LoginVO = loginProxy.getData() as LoginVO;

Or would it be generally a bad idea to retrieve the shell from another core doing it this way?

Thanks in advance,
Olaf

Thanks Cliff, l'll go that way!

Olaf

Argh... I've just seen/remember that Cliff already gives an answer to a similar approach in the past:

The problem is that you can't guarantee that notification constants aren't in conflict across modules. Particularly in a situation where third-party modules are provided. A core's message space is its own. That' why pipes has a message facility that can pass between modules safely.

So I have to make sure that a notification constant is unambiguous across all cores!
Are there any other concerns?

Thanks,
Olaf

Hi,
I just stumbled over an old question wich probably was already discussed in the past.

However, from the shell I'd like to inform all "registered" cores with the same information and wonder if it has any drawbacks
to just loop over the core instances and call the sendNotification() method of their particular facades:

E.g. we could have a "cors getter" inside the shell facade to make the core instances accessible and a command "NotifyCores" that resides in the shell:

ShellFacade.as:

:

public class ApplicationFacade extends Facade
{
        ...

/**
        * Make cores accessible
        */
public function get cors():Array {
   return instanceMap;
        }
}

NotifyCoresCommand.as:

:

public class NotifyCoresCommand extends SimpleCommand
{
override public function execute(note:INotification):void {
                // E.g. use the "type" property to pass the notification name
                var type:String = note.getType();
                
for each(var core:IFacade in ApplicationFacade(facade).cors) {
core.sendNotification(type, note.getBody() );
}
}
}

This would make the "shell->cores" communication very easy without involving the view using interfaces or using the pipes utility.
The only thing that the shell and the other cores has to share would be the note name (Like the "message" in the pipes utility, if I remember it correctly).

Are there any concers with this approach?

Thanks,
Olaf

Sorry for not providing the "Undo Multicore" version until now.
As soon as I'm finished the work on a "Undo Multicore" demo I'll do a pull request for the lib.

Olaf

Very nice! Simple and clean as the framework itself ;-)
Thanks for keeping up the great work on PureMVC Cliff.

Olaf

No, you can only use multicore version in a multicore project, and standard in standard. The project just contains the source of both.

Yes for sure ;-)
I was wonder merely if there's a tricky way to put both into one FB project with the only goal to push it directly to the github repo without the need of merging it manually.
But at the end it's probably more effort to discuss this here instead of just doing to it ;-)

Thanks,
Olaf

I'd say using the Notifier class which is common to both apps using PureMVC would be a reasonable way to do it

I think I'll try it this way.
Many thanks for your continued support, I appreciate it!

Olaf

Hi,
I've doing some tests using PureMVC with FlexJS and it seems that it works fine.
(If it makes sense I'll publish a PureMVC FlexJS version as soon as I'm able to create a swc of it)

What I'm currently trying to achive is to outsource the complete business logic to a pure AS3 lib using PureMVC.
My goal is to be able to switch between the "Flex standard SDK" and "FlexJS" without changing any line of the business logic. So the business logic has to be free of any flash or flex dependencies.

Cause the mediators main purpose is to handle view events it has a depenency to flash.events.Event (or org.apache.flex.events.Event for FlexJS).
To resolve the dependency to the view itself I'm using interfaces and that works fine.
But the interface itself also has currently a dependency to IEventDispatcher.

So I'm searching for a solution that makes the business logic flash/flex free while putting as much code as possible to it. In best case the app that uses the "business logic lib" tells the lib which kind of Event implementation it has to use respectively pass the 'right' Event implementation to it... some kind of a switch.

One solution that comes in my mind is to extend the concrete mediator, overwrite all methods that depends on Event and make it part of the app that uses the lib. But this would mean additional code.

Any ideas how to achive this much more elegant?

Thanks,
Olaf

:


// How to get rid of it?
import flash.events.Event;
//import org.apache.flex.events.Event;

public class MyMediator extends Mediator implements IMediator
{
    public static const NAME:String = 'ApplicationMediator';
    
    public function ApplicationMediator(component:IViewMyView) {
        super(NAME, component);
    }

    override public function onRegister():void {
super.onRegister();

         view.addEventListener(ApplicationEvents.DO_SOMETHING, onDoSomething);
    }

    // How to get rid of Event?
    private function onDoSomething(event:Event):void {
    }

    public function get view():IViewMyView {
        return viewComponent;
    }
}


:


// How to get rid of IEventDispatcher?
import flash.events.IEventDispatcher;
//import org.apache.flex.events.IEventDispatcher;

public interface IViewMyView extends IEventDispatcher
{
    function setData(data:String):void;
}


>please have a look at https://github.com/PureMVC/puremvc-as3-util-statemachine which has both a >standard and multicore version in the same repo

Do you merged the standard and multicore version manually to one repo or is there a way of having both in one (FlashBuilder) project?

Thanks,
Olaf

Thanks Cliff, I will check it out.
Olaf

Hi Cliff,
I've already done the port to Multicore.
Additionally to the changing of the imports, I've had to inject the multitonKey at one place to get it work.
(See my post above).
Don't know if this is a proper way but it seems that it works. I'll test it a bit next days.

And yes, it would be great if you could create the GitHub repo!
I could create a pull request to this new repo that would contain all the files so that you could get it with less effort.

Olaf