Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
August 23, 2017, 06:19:17 PM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
Pages: [1]
Print
Author Topic: Multicore PureMVC with Routing  (Read 6920 times)
saad
Sr. Member
****
Posts: 65


View Profile
« on: September 23, 2014, 12:51:50 PM »

This question is in context of a JavaScript Application where angular has been employed for routing and to watch for hash changes in a browser.

Should we implement multiple routing for each submodule or implement single routing system. I'm facing some challenges with multiple routing but I see some pro's and cons for each.

A
Each submodule listen for it's own set of hash changes and acts accordingly (Added benefit is that it let's you specify it's own function calls within it's "scope" and automatic execution on hash changes, Independence etc.)

or B
Shell implements the routing system and broadcast changes via junction to all of it's submodules. Submodules listens to Routing notifications and steward viewComponents to different states or execute commands etc.

Personally I see the implementation B best though I'd lose some benefits of integrated angular benefits but I had a different case as well in a PHP implementation. A specific submodule was loaded based on the first part of the route, and then the submodule branches off and decides the operation based on the 2nd part. I was looking at my current project in the same context.

In SOAMusicPlayer, I've noticed the Browser Mediator and then it seems Shell acts on it independently without requiring submodules to do anything, but in a situation where submodules need to act as well, what's the best way to achieve from the above?

In some earlier implementations of AS3 with SWFAddress that I've seen, the routing was implemented in a proxy implying it as a data/information and in the case of SOAMusicPlayer it's a viewComponent managed by BrowserMediator. Please also expand on this.
« Last Edit: September 24, 2014, 06:19:49 AM by saad » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2870



View Profile WWW
« Reply #1 on: October 02, 2014, 06:52:28 AM »

I believe I'd implement a mediator in the shell which takes the input from the hash and 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. If a module needs to change the hash to reflect internal state change, it could send a pipe message back to the shell which would handle that. That way, each module doesn't have to know anything about the hash. And it would be more testable, because you create a mock BrowserMediator that could send those messages without actually making hash changes, to see that the modules respond.
Logged
saad
Sr. Member
****
Posts: 65


View Profile
« Reply #2 on: October 02, 2014, 02:40:37 PM »

much better  Smiley. Thanks Cliff.
Logged
saad
Sr. Member
****
Posts: 65


View Profile
« Reply #3 on: October 02, 2014, 09:00:55 PM »

I've a different case too in context of PHP where things are different, since PHP is a stateless environment, Shell, Modules are loaded at runtime, request is handled and response is returned in a fraction of a second. my workflow would be as follows, please comment for any suggestions.

In a multicore application let's say with 8-10 Modules, Shell is instantiated for each request but then depending up the params, only the required modules (generally 2-3) are instantiated, plumbed and executed because of the efficiency reasons.

The application needs to determine route information the very first thing after the STARTUP before anything could happen, Plumb, configuration everything will follow.

A. In BrowserMediator, after determining route information, it will transition the StateMachine to PLUMBING state hence firing the PlumbCommand along with route information in the notification body, inside a switch statement, the PlumbCommand will instantiate only required modules (based on the first part of the route) and plumb them together.

B. PlumbCommand will transition the StateMachine to the NAVIGATING state passing the given route information in the notification body, NAVIGATE notification will be triggered, passed to ShellJunctionMediator that will STDOUT the route information to the modules so they can further branch execution based on the routing.

Please suggest for any enhancements.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2870



View Profile WWW
« Reply #4 on: October 06, 2014, 06:26:14 AM »

You could run a fully plumbed app as a daemon, and pass requests to it from a simpler CGI app, bypassing the complicated startup each time.
Logged
saad
Sr. Member
****
Posts: 65


View Profile
« Reply #5 on: October 06, 2014, 08:25:49 AM »

that's extraordinary  Smiley
Logged
saad
Sr. Member
****
Posts: 65


View Profile
« Reply #6 on: July 24, 2016, 07:33:50 PM »

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.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2870



View Profile WWW
« Reply #7 on: July 28, 2016, 06:27:15 AM »

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>
Logged
saad
Sr. Member
****
Posts: 65


View Profile
« Reply #8 on: July 29, 2016, 06:09:48 PM »

Thanks Cliff. I'll go for the broadcast option, but surely listSubscriptions gives another perspective on inter-module communication Smiley
« Last Edit: August 01, 2016, 09:35:30 AM by saad » Logged
Pages: [1]
Print
Jump to: