Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
May 24, 2017, 08:21:41 PM
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: 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>

 22 
 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

 23 
 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

 24 
 on: August 14, 2016, 03:05:59 PM 
Started by openoli - Last post by puremvc
Thanks Olaf. For a few years I filled all my extra minutes writing a novel. When I got that out the door, I also found myself executing a transition to HTML5, and figured it was time for me to do something about this ancient site. I'll also be taking a more active role with the JavaScript port now as well.

Cheers,
-=Cliff>

 25 
 on: August 12, 2016, 01:03:15 AM 
Started by openoli - Last post by openoli
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

 26 
 on: August 12, 2016, 12:56:47 AM 
Started by openoli - Last post by openoli
Very nice! Simple and clean as the framework itself ;-)
Thanks for keeping up the great work on PureMVC Cliff.

Olaf

 27 
 on: August 01, 2016, 07:53:36 AM 
Started by puremvc - Last post by puremvc
Hey Saad,

Just received the following email from William Rena at Arcanys Inc.:

Quote
Hi guys. You are doing great with your PureMVC Framework. I used this when I was in Flash Development. I"m a great fan with this framework especially the new PureMVC Swift. I'm currently exploring and learning to adapt this framework and use it in our team. Do you have an example how to use the Pipes and State Machine in Swift?

Do you have any code or notes up your sleeve on this subject?

Cheers,
-=Cliff>



 28 
 on: July 29, 2016, 06:09:48 PM 
Started by saad - Last post by saad
Thanks Cliff. I'll go for the broadcast option, but surely listSubscriptions gives another perspective on inter-module communication Smiley

 29 
 on: July 28, 2016, 06:27:15 AM 
Started by saad - Last post by puremvc
I think the broadcast option is best, since you never know what coordination patterns may be needed between various modules when a hash change occurs. And by trying to put all the knowledge in the shell about what modules need to respond to what hashes, you sort of defeat the encapsulation of a modular system.

You could, of course have each module, upon connection, or in response to a broadcast pipe message, respond with a list of 'subscriptions'. So that the shell is then able to realize on a given hash change which modules to send the message to.

Cheers,
-=Cliff>

 30 
 on: July 24, 2016, 07:33:50 PM 
Started by saad - Last post by saad
Hi Cliff,

Building on the same thread but consider the scenario on the server-side for the node.js environment with several modules plumbed to the Shell and I quote

Quote
sends pipe message on a STDOUT pipe to all plumbed modules. That message would pass the hash fragment to the modules, and any that need to respond may do so.

Will this be considered inefficient if each requestVO (request/response) is broadcast to all modules while knowing that only one will handle it. Although with this strategy I can connect a Filter to each module's Junction's STDIN and check for URL segment (/customer, /product) before I let it in to respond and fulfill the GET/POST request.

The other strategy is to determine the destination within the shell in a Command, then send Notification (body: requestVO type: pipeName) followed by JunctionMediator's writing to a specific named Pipe. (Con: possibly will have too many checks/branches based on number of modules)

Personally I'd like to go for the broadcast option, please advise.

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