That would be really cool.

Hi Cliff,

Just saw this now, I would love to setup a demo for Pipes, something like Prattler demo.

The idea is to create additional framework libraries within the XCode project serving as modules, each one having it's own storyboard, viewComponents, commands, proxies and delegate objects. The viewComponents will then be piped to shell on requests etc. where they would be added to the hierarchy (remove etc.). The visual component management and layout within XCode has changed a lot recently, hopefully the recent changes will be final.

StateMachine is simpler, a demo similar to StopWatch should suffice. Will try to get on them soon.

Thanks a ton to Saad Shams for taking time from his busy schedule to bring the port up to date.

Thanks a ton to Saad Shams for taking time from his busy schedule to bring the port up to date.

Thats the ticket. 

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

If you package your model in a separate library, then each core can use it. You could make the LoginProxy have a class property that holds the ProfileVO. That would let you register it in every core, retrieve it, and be able to access the login info that was fetched by the instance in the shell. Make it 'protected static' and add a getter for it.

Cheers,
-=Cliff>

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

Nope, that's pretty much it. If you control all the modules that will ever run in the app, and come up with a scheme that ensures the notification type values are all unique to the core they're intended for (eg., VIZ_CORE_STARTUP = "Core/Visualizer/Startup", or ALL_CORES_LOGOUT_RESET = "Core/All/ResetAfterLogout"), what you want to do will work.

Like pipe messaging, you'll want to create a common notification constants library used by all modules. Define all your notifications there instead of inside the individual Cores, that way they're all reading from the same page when it comes to intercore communications.


Cheers,
-=Cliff>