Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
June 23, 2017, 03:16:11 AM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
Pages: 1 2 [3] 4 5 ... 10
 21 
 on: December 11, 2016, 11:00:16 AM 
Started by puremvc - Last post by puremvc
Thanks a ton to Saad Shams for taking time from his busy schedule to bring the port up to date.

 22 
 on: December 11, 2016, 10:59:36 AM 
Started by puremvc - Last post by puremvc
Thanks a ton to Saad Shams for taking time from his busy schedule to bring the port up to date.

 23 
 on: August 30, 2016, 11:03:16 AM 
Started by openoli - Last post by puremvc
Thats the ticket.  Smiley

 24 
 on: August 29, 2016, 07:31:05 AM 
Started by openoli - Last post by openoli
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:
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

 25 
 on: August 27, 2016, 07:19:23 AM 
Started by openoli - Last post by puremvc
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>

 26 
 on: August 25, 2016, 12:36:39 PM 
Started by openoli - Last post by openoli
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;
Code:
// 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:
Code:
// 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


 27 
 on: August 21, 2016, 09:59:50 AM 
Started by openoli - Last post by openoli
Thanks Cliff, l'll go that way!

Olaf

 28 
 on: August 20, 2016, 08:11:22 AM 
Started by openoli - Last post by puremvc
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>

 29 
 on: August 19, 2016, 07:55:22 AM 
Started by openoli - Last post by openoli
Argh... I've just seen/remember that Cliff already gives an answer to a similar approach in the past:

Quote
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

 30 
 on: August 19, 2016, 06:38:22 AM 
Started by openoli - Last post by openoli
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:
Code:
public class ApplicationFacade extends Facade
{
        ...

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

NotifyCoresCommand.as:
Code:
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

Pages: 1 2 [3] 4 5 ... 10