...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.

The rules of thumb for factoring view components down into smaller and smaller units is the same regardless of framework usage. Don't build god objects. Break it down. Remember that reuse is a by-product of this process, not the goal or the arbitrating factor in the decision to decompose further. The goal is make each component simple enough to be able to do its function clearly so that when someone needs to modify it, it's an easy task, and no cycles are spent trying to understand how everything is wired up. The component should expose an api of properties and events that make it obvious what its external dependencies are and what things about its state it will communicate to the rest of the app.

Since view components are arranged in a hierarchy, the parent view component can and should act like a mediator to its children. PureMVC Mediators are not code-behind constructs intended to push you toward developing "dumb" components. They only provide framework mediation with chosen parts of the display list. Every component doesn't have to be mediated. You might have twenty view components but only three Mediators. The mediator can pass data to its view component, which passes it to its children, and in turn they pass it down to their children. Those grandchildren can send events up the display list that, if need be, eventually make it to  a mediator via the grandparent.

You can even have the view component implement an interface so that it can pass itself along in the event, and the mediator sets data directly on that requesting grandchild component rather than on the component it actually mediates.

A mix of data being passed from a mediator to a component and from there down the display list AND mediators communicating with arbitrary interface-implementing components is good. In the right balance, a mediator can service a lot of components, the data flow in the display list doesn't get too complex, and the mediator's responsibilities aren't overwhelming.

So, decompose your interface, then look for appropriate points to mediate. Find that sweet spot where the display list, the individual components, and the mediators are all at a comfortable level of complexity.

Cheers,
-=Cliff>

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.

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.

Let the shell expose an interface. It can act as a mediator between the modules and the outer framework.

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.

Nice.

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 2.3.3.1).

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.

That looks great. Did you think about the possibility of running this as a daemon so that you don't have to load and plumb the whole app for every request?

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.
https://github.com/sshams/Entitlement/blob/master/src/Application.java

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.
https://github.com/sshams/Entitlement/blob/master/src/modules/entitlement/view/components/Router.java

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.

If the application gets large it could be an issue. Can you set the application up to run as a daemon and then connect to it from a more lightweight servlet? You could instantiate a pool of modules to handle requests, and plumb a new one when needed, then return it to the pool when complete.