Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: [1] 2 3 ... 5
1  PureMVC Manifold / Demos and Utilities / Re: StateMachine - A PureMVC Swift Utility on: December 23, 2016, 12:03:54
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.
2  Announcements and General Discussion / Architecture / Re: Multicore PureMVC with Routing on: July 29, 2016, 06:09:48
Thanks Cliff. I'll go for the broadcast option, but surely listSubscriptions gives another perspective on inter-module communication :)
3  Announcements and General Discussion / Architecture / Re: Multicore PureMVC with Routing on: July 24, 2016, 07:33:50
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

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.
4  Announcements and General Discussion / Architecture / Re: Bulky Modules on: December 14, 2015, 12:20:47
agree and yes it's appropriate to do in module while add or remove happens in shell.

Saad  :)
5  Announcements and General Discussion / Architecture / Re: Bulky Modules on: December 14, 2015, 10:24:52
Hi Cliff,

Yes that's exactly what I've been thinking for and thanks for making it more clear and cut.

Further I intend to link domain logic that's reusable across modules under the light of "Reusing the Model Tier" topic from PureMVC book while this complex "View" (in a submodule) can have it's own internal "Controller" and "Model" as well depending upon the need. The shell can further steward this viewComponent after addition and mediator registration etc.

The ultimate objective is to have each "Complex viewComponent" developed from different team members while giving them an independent clean slate (their own small manageable module, scripts, .fla, .xib etc.) to work on and then getting all of those complex viewComponents assembled within the shell as per your guidelines hence leading to less bulky "View" of the shell.
6  Announcements and General Discussion / Architecture / Re: Bulky Modules on: December 14, 2015, 03:58:34
Thanks Cliff. The idea was to have parts (complex nested components) of "View" to be developed across modules instead of compressing everything within the shell while also maintaining the hierarchical relationship and mediation in shell.

Thanks again for a very comprehensive discussion on large scale enterprise development under PureMVC.
7  Announcements and General Discussion / Architecture / Re: Bulky Modules on: December 06, 2015, 02:28:00
Thanks Cliff for the enlightenment and an improved workflow. It's good to learn how Mediator can mediate it's viewComponent as well as it's nested components.

Building on the thread and pushing "View" related discussion a bit, let's say those twenty or more viewComponents are split across modules/cores. The primary purpose is so that different individuals/teams can work independently on assigned viewComponents without the need to access or share the shell's root file (.fla in flash, .xib in iOS etc.).

Just like in the Pipes Demo, the prattler module gets it's own clean slate for development, UI related components, it's own controller and model, and is piped to the shell where it gets added there along with it's Mediator registration.

Please add your gems for a case when we have several complex components like prattler or more distributed across modules and dev teams in a large scale app.

Thanks again.
8  Announcements and General Discussion / Architecture / Re: Using PureMVC to build SDKs, Libraries and Frameworks on: October 06, 2015, 08:04:18
Thanks Cliff. I've finally worked out an implementation, since SDK is a multicore and internal communication is Async using pipes, so users of the library have to submit a Formal Request providing requestData, requestType and a callback (native kind) while shell is exposing an interface to that.

Based on the requestType the shell pipes the request to respective module, and once it gets back the serviceRequest with resultData it notifies the observer in a command that in turns calls the user's callback method.

This one is for non PureMVC users and inner PureMVC implementation is hidden.

For PureMVC users which I've not implemented yet, the idea is shell inheriting from PipeAwareModule and connecting the input/output pipes to shellJunction and then I think I'd need an Uber Shell that connects the user's module and SDK's module.
9  Announcements and General Discussion / Architecture / Re: Bulky Modules on: October 06, 2015, 07:43:12
Hello Cliff,

Formal Request pattern has been amazing. A single command with a single proxy and some advanced type of ServiceRequest (added property requestType) while utilizing a highly reusable helper object (like RemoteObject, DatabaseObject etc.), not only turned controller into a thin controller but a thin proxy as well. Single Invoker/Responder principle worked a ton.

I saw the same great principle getting implemented in The Advanced View Topics in "ActionScript Developers Guide to PureMVC" under Managing Pop Ups. Deep stuff.

"A Proxy retrieves the data from a service and a pop up retrieves it from the user; that is the only difference."

Controller, Model and Popups are very much under control :) but when I've several view/components in an app (let's say Header, nav and their associated pages, login and profile panels and several others), I see explosion of mediator and viewComponent classes.

An idea is to divide viewComponents across different cores while reusing the Model Tier (Chap-8 Advanced Model Topics), and maybe have the nav in the shell with management of add/remove pages but classes of associated views/pages in different cores. Any thoughts on that please.
10  Announcements and General Discussion / Architecture / Using PureMVC to build SDKs, Libraries and Frameworks on: September 03, 2015, 01:35:41
Hello Cliff,

I'm brainstorming on the architecture and how to approach building API's and Library Frameworks using Multicore PureMVC that can be linked by both PureMVC (preferably) and non PureMVC apps.

Typically ShellModule/ShellFacade can be instantiated that further instantiates other modules and plumbs them. Can you please comment on what'd be the right approach to leverage the functionality of those modules from outside the Shell and get results back from their inner workings.

Basically the intent is using PureMVC framework to build other Frameworks. Thanks.
11  PureMVC Manifold / MultiCore Version / Re: Java Servlets with PureMVC on: July 30, 2015, 04:28:24
yes and I didn't have to since ServletContext is loaded only once for the entire life of the container, that's where the shell/ApplicationFacade and modules are instantiated and plumbed. Tested with log statements and concurrency testing through multiple machines so shell and modules instantiation and plumbing happens for once only. https://github.com/sshams/Entitlement/blob/master/src/Application.java

Each request is handled through a single instance of the servlet but concurrency is achieved by running requests on separate threads.

But things can flip around if Developer implements SingleThreadModel (not recommended)
More on http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/ (Section

Then in that case there would be a pool of Servlet/Router instances (but still not shell and modules) maintained by the container. In that scenario the workaround would be to manage a counter id and register a new RouterMediator (NAME + id) for each new Servlet/Router instance in a command.
12  PureMVC Manifold / MultiCore Version / Re: Java Servlets with PureMVC on: July 30, 2015, 09:19:07
Hi Cliff,

I've worked out an implementation with some inspirations from SpringMVC with application of FrontController pattern to Servlets. https://github.com/sshams/Entitlement (Customer/Product Demo)

There are three major integration points to connect the Servlet (Router) to the PureMVC apparatus.

1. ServletContextListener on contextInitialized instantiates the ShellFacade and passes servletContextEvent to startup. StartupCommand then instantiates modules (and plumbs) and registers them with the ServletContext using attributes.

2. common/PipeAwareModule includes acceptRouter function which then sends out the notification with router in it's body. RouterMediator responds to this notification to and sets the router as it's viewComponent and sets itself as a Delegate.
   a) https://github.com/sshams/Entitlement/blob/master/src/common/PipeAwareModule.java
   b) https://github.com/sshams/Entitlement/blob/master/src/modules/entitlement/view/RouterMediator.java

3. Servlet (Router) on init method retrieves it's related Module from Servlet Content and calls acceptRouter and passes itself.

Each additional module will have it's own Servlet/Router defining it's own set of URI's and will receive the Router via acceptRouter just like above.

So far it worked out fine but I'm open to any ideas, any other strategies that can polish it further from you or the community.
13  PureMVC Manifold / MultiCore Version / Java Servlets with PureMVC on: July 02, 2015, 09:27:10
Hi Cliff,

Trying to get my head around implementing a plumbed multicore app with Java Servlets, wondering if there's an implementation or if you can please guide for startup mechanics. I see Servlet as Front Controller/Router intercepting requests and delegating on to PureMVC apparatus via it's Mediator. I've following steps under review.

1. Define a class implementing ServletContextListener that loads with the application server, instantiate Shell and other modules inside contextInitialized method, and plumb them followed by shell and module registration with the Servlet Context so references are available to Servlets in #2

2. Servlets are lazily instantiated and are available after ServletContext is constructed. Within each servlet's init method get reference to custom ServletContext, then reference to Shell or Modules and using a method like acceptRouter along with acceptInputPipe/acceptOutputPipe while passing this so a RouterMediator can be set upon it.

Any thoughts?
14  Announcements and General Discussion / Architecture / Re: Bulky Modules on: June 23, 2015, 01:27:56
Hi Cliff,

It's awesome and much better now. Took the Formal Request route, not only the modules are compact now but actors are thin and manageable as well.

Using a SimpleCommand and a Proxy, although the environment is node.js but adopted few things from Flex paradigms, for instance common.DatabaseObject (RemoteObject in Flex) which itself now is a highly reusable actor across all modules, accepts the QueryRequest/Observer (sql + values + request/response objects), returns the token on which Proxy sets itself as a Responder. DatabaseObject then pools the connection, executes the SQL and returns result/fault via token.responder to the Proxy.

Model got reduced to a single proxy that just populates the sql string and values array of QueryRequest, and notifies the command on result/fault. Further View tier (Router) is handling result decoration as per the REST specs for the client.

Thanks a lot for your great support.
15  Announcements and General Discussion / Architecture / Re: Bulky Modules on: June 15, 2015, 05:28:51
Hi Cliff,

I apologize for not been able to respond earlier as I've been completely slammed, but I read the response, been pondering, also looked up the book reference and I understand the points mentioned here too, but here's something which led to this structure and I'd explain more with the help of your quote.

It would need a method for each of list/detail/insert/update/delete, but its handling of the response would be similar.

It's basically the handling of the response that's different for each of the actors. for instance.

  • GET /products -> 200 OK [] (Array)
  • GET /products/:id -> 200 OK {} (Object) or 404 Not Found
  • POST -> 201 Created
  • PUT /products/:id -> 200 OK or 204 No Content
  • Delete /products/:id -> 200 OK or 204 No Content

And there's more to the REST specifications not covered here, for instance content negotiation factors or decorating the result with the link of the newly created resource in the response headers for POST commands.

So it's very different, unique and detailed post-async or post result/fault responsibilities for each kind of request that are the reasons behind separate AsyncProxies with their dedicated roles.

Initially I did combine 1) List and 2) Detail and tried with a single actor but due to async nature of node.js itself (callback for everything) it was turning into a Fat proxy and from there I split up things and assigned single responsibility/role to each actor.


With reference to AsyncCommand, PureMVC book referred to it as
muddle the responsibilities of the Command, making it implicitly involved in the persistence mechanism by implementing Responder and handling ResultEvents and FaultEvents

I agree and I could have Proxy send notifications (RESULT/FAULT) after result decoration but it's because of the nature of node.js and following simplicity measures that employed AsyncCommand.

node.js runs under a single process (shared/single memory space for all users) and in order to serve multiple users, a new instance of proxy has to be created for each request in a command, i.e. no registration of proxies in StartupCommand, since all actions within the proxy are async so a single instance can't be used for another request while it's asyncAction is in progress.

Then for it to be able to send notifications for result/fault it needed facade registration with a unique name (Proxy.NAME + request.id) and then has to be removed at the end to release memory, so a dedicated command was required for that. I could create another method within the proxy that remove itself from facade at the end, but then re-using the same command that instantiated it seemed more intuitive for removal, so that's how a dedicated pair concept came into existence.

Later on, I simplified things, for each request a new AsyncProxy instance gets instantiated but without repeatable facade registrations and removals, it performs it's asyncActions, parses results, decorates it, and then it responds back to it's paired AsyncCommand for sending notification. AsyncCommand frees up a bit from having to register and remove proxies from facade. By handling result parsing/decoration within the AsyncProxy and responding to AsyncCommand for notification only, I hope that avoids the muddle while also keeping the AsyncCommands thin.

So in summary, each request fires it's notification, for which Controller instantiates a new Command, and that command in turns instantiates a new proxy, calls asyncAction on it, the proxy then pools the connection, executes the SQL, decorates the results first within it's own result/fault handler, and then responds back to the Command for RESULT/FAULT notifications. All of this is happening in parallel/sequence for all the requests. These new instances of AsyncCommand/AsyncProxy pairs for each request is basically making it possible to serve several different user requests under a single process environment but then at the same time exploding the module.
Pages: [1] 2 3 ... 5