I like the idea of delegation to solve the component->mediator communication problem.

In Flash, where we have a built-in Event system, so it was convenient to decouple the component entirely from its mediator. In JS, we have to build our own event system or make use of some 3P lib. In that light, passing a closure to the component is a reasonable approach. Much better than giving the component a direct reference to the mediator.

Hi Saad,

Not sure we need onComplete in the sub AsyncMacroCommands if the uber deals with them properly in sequence.

-=Cliff>

Sorry for the delay. I've had several unexpected time-sinks thrown at me these last few months.

In that time, I've received a version that is built in pure JS using prototypes. I'm currently looking at the two to determine what's best. We added the PureMVC faux-class style so to make it easier on devs, but I'm not yet sure we want to build the utilities based on it.

Please have a look at the most recent posts in this forum from Saad, who has put the Prototype version forward. Perhaps we can discuss the pros and cons in these threads and you could have a look at his code and give your thoughts on which is the better way to go. My primary expertise is in Flex/AS3 so, I want to be sure to get the best input from JS devs on the JS port/utilities before making command decisions. 

Cheers,
-=Cliff>

Excellent! Thanks for the update.

Sweet. The code looks lovely. Would you like to contribute it to the project?

On GitHub, I've been creating a new repo owned by PureMVC and accepting pull requests for changes. That would mean you'd then fork this project and make pull requests against that.

That's kind of a pain, since you already have the project in Github, but I'm not sure if forking your project is the right move. Do you have thoughts one way or the other?

Cheers,
-=Cliff>

"I also notice that for some reason my StartupCommand is called twice, or at least instantiated twice"

I'd start by figuring that part out. Something's seriously out of whack with your startup process.

I think whatever's triggering the PrepViewCommand when it shouldn't is not sending the app in the notification. That would mean that app is null and therefore the cast to MovieClip in line 15 would fail.

It doesn't have to be an either/or decision. You could use PureMVC for MVC separation, while using angular for data binding within the view, for instance. Have a look at the PureMVC EmployeeAdmin demo for Flex. It's a good example of how a framework with data binding can help your view components to pass data between subcomponents, while still using PureMVC to shuttle data from view components to the model and visa versa.

Running the same framework on client and server can definitely be a good if developers are called upon to work both sides of the fence. And for the system architect to design.

With a long-running server process (not a CGI request where the program gets run each time a request is made):
* Model classes (Proxies) communicate with databases, other processes, remote servers, etc.
* View classes (Mediators) maintain individual client sessions
* Control classes (Commands) perform logic such as transforming an HTML template with data, or format a JSON or XML response
* Facade handles startup of the server app, as well as creating Mediators for new client sessions. In some languages this interprocess communication would be handled with forking and pipes, in Java it would be via threads and synchronized objects.

Client
has an PUREMVC JS based port on web server (maybe apache reverse proxy)
-- hosts the Client Side delivering only the static images and static HTML
-- (DIVS for content layout and empty HTML5 TEMPLATE for content)
-- reverse proxy passes client commands back to application server VIA AJAX formatted as JSON

Server
has an PUREMVC JAVA based port hosted on J2EE App server (maybe Glassfish)
-- hosts the Server application
-- No JSP's or content handlers to output html
-- App Server only accepts data requests from client via AJAX and returns formatted JSON

Sounds like a reasonable setup (although I believe AJAX that returns JSON is now commonly referred to as AJAJ).

Trying to avoid
URL Params

So, your request parameters would go as HTTP headers? If you're not passing the request info via URL params or the path, then headers is all that's left.
 

REST as it's to tightly coupled to HTTP

This seems directly at odds with your spec above. AJAX/AJAJ implementations typically build upon XMLHTTPRequest, which is intimately coupled to HTTP. REST is just a way of letting you think about your request space in a tree form. It's a simple way to pass information to your service about what you want. As are URL params. Again, you have to pass that info some way, and the only way you've left is HTTP headers, which is as tightly coupled to HTTP as you can get.

WEB Services (wsdl or soap) as its XML is  too verbose[/quote]
I agree, although most browsers and servers are capable of gzipping requests and responses now, so it's less of an issue than it once was.

I look forward to hearing about your progress.
-=Cliff>

The initializeController() method is present, but it was deemed just as easy for the startup() method to register the StartupCommand and then trigger it.

In this particular application, the methodology of putting the registration of commands into a sub command of StatupCommand was implemented, which is an alternate way of doing things that reduces the number of classes the Facade has to know.

Question: how can I get a module's STDOUT to work as a broadcast to other multiple modules it maybe connected to?

Use a splitting tee on the module's STDOUT, and a merging tee on the STDIN to the other modules that need to hear the broadcast. It's like plumbing really.

No, no, sorry, Luis.

I wasn't saying I personally refused to make the change. I was just saying my advice to you was not to modify the FSM, but to either a) pass the data through from whatever actor sends the note to make the state change, b) to have the command look at the note name and decide what file to download, or c) define those filenames in a different place, perhaps hardcoded in a Proxy, or in an XML file a Proxy reads, so that the command can invoke a method with a key to a map that the Proxy uses to figure out what file to download.

You're certainly free to modify the source code and do what you like, that's the beauty of Open Source. However, I've just seen in the past that usually, that's not the best option, and left as a last resort if there is absolutely no other way you can do the thing.

Cheers,
-=Cliff>

Absolutely. Freedom can easily become anarchy in a large app with many devs. Having specific ways of doing things keeps everyone on the same page. Sometimes you think you're oppressed and having your freedom taken away, but then without the framework and the patterns, you find you have to solve so many mundane patterns and make so much spaghetti while you do it, that freedom turned out not to be so great after all.

You can already pass data between States. When sending a StateMachine.ACTION notification, you may include any Object as the body of the notification and it will be included in the state-specific 'exiting', 'entering', and 'changed' notifications. This allows, for instance, the data collected from a UI form in the 'DATA_ENTRY' state to be passed to the 'DATA_SAVING' state when the form's 'Save' button is pressed.

That might help or it might not. But I'd still declare the files to be loaded elsewhere, perhaps in a Proxy. And I'd locate the downloading code in the Proxy as well. The Command, should be able to look at the state and make the appropriate call to a given proxy.

Are you really downloading hundreds of files? Do you really expect this Command to be expanded to do that? If not, then I'd not try to constrain the architecture to doing what is needed now and in the foreseeable future. You don't want to preclude things, but you also can't code for every eventuality (and hit deadlines). Sometimes you have to do what makes sense for the planned usage, then refactor when and if things change.

In short, no, I don't think I'd make an on-the-spot modification of the FSM when there are other obvious ways to allow the Command to know, based on the new state, what it needs to do.

Register the same command to two different notifications. Inside the command, check the notification name to decide what file to download.

Cheers,
-=Cliff>

Regarding simplicity, PureMVC is a tiny handful of patterns, but every app you write will use those patterns over and over. All your programs will essentially look the same. This makes it easy to bring developers up to speed on 'how things are done', and there are plenty of folks out there who already know.

With DI (again, not talking about RL, only DI in general), you're not encouraged or required to use patterns other than injection. This means on a large team, people often do the same things in many different ways. That leads to programs that are difficult to understand, debug, and evolve. If everyone is using the same handful of patterns to get things done, then it's much easier to follow.