I believe that the standard version (which has had quite a tumultuous history, to say the least) was last re-implemented by a team who was focused on GWT, and one problem (as I understand it) was that you couldn't pass a class reference. Perhaps GWT doesn't (or didn't) have reflection support, I'm not sure.

You're right! I remember the whole history now. I was quite surprised of this.

could you look at whether GWT can pass class references around?

I don't think I will have time before a while for that. I already have too many things on the grill to finish before. I even tried to recruit someone interested in PureMVC Java recently:https://github.com/ndeverge. Nicolas kindly made a pull request to add Maven support to the Java standard port I was hosting on my own Github for the work on converting it from multicore. Now that even PureMVC is on Github I will push it back to PureMVC Github. I may ask him again if he is interested in this problem.

The update from Class commandClassRef to ICommand command has been made when upgrading the PureMVC standard Java framework from PuremVC Java multicore framework.

I'm not too much on Java development, but I did the upgrade myself to help the community because we had many silmutaneous problems with the standard framework. I near have copied the multicore framework and converted it back to standard. To be honnest I don't remember that it required to use an ICommand instead of a class reference. It would be better to use a class reference here if we really can without unknown side effect.

For your exact problem, this is normal that the compiler throw an error here as the type on the object you pass as an argument is not an ICommand but really a Class object.

And another issue is that the current documentation tool (jsduck) can't follow the PureMVC define() hierarchy

I can't help you on this, I worked with JSDoc by the past, I also had many problem with it too and I've never worked with jsDuck. Tomorrow I've planned to start the work on PureMVC JavaScript standard framework. I also has to create help using jsDuck I hope I won't have any problem with it either.

Next to this work, I'll have a look into the full super implementation with PureMVC define().

I just published a blog post announcing the brand new PureMVC for TypeScript framework http://www.tekool.net/blog/2012/11/07/puremvc-for-typescript/

I hope soon on PureMVC as new supported language.

Also, there is a PureMVC Dart port. Dart has proper inheritance and typing.

Yep but tell me if I'm wrong, Dart's compiling to JavaScript is not really intended to be executed on the web. What is the status of Dart to JavaScript compiling? It seems to have been critized a lot by the past.

I checked out John Resig's solution, which seems proper. I don't know what it would take to adapt it to the oop.js class, but its worth looking into.

I can have a look into porting the John Resig solution into PureMVC. I have studied those kind of solution when working on Objs. Objs uses a system pretty near than the one from the John Resig solution (my solution is quite older than his, I'm kind of proud of it). In 2008 and before, it has one main caveat, it absolutely needs JavaScript to support the constructor keyword. Some old browsers doesn't support it (it even can cause serious issues with some Safari versions). But to be honnest today no one care, even TypeScript output an extend method that make use of constructor (I checked and PureMVC define even already use it).

From what I remember the idea of John Resig also can cause some issue with an inheritance chain where :

1) The SuperClass define a method.
2) The first subclass doesn't define this method.
3) The third subclass define this method and makes use of the super method.

From what I remember the call to super will not work where it has to, it has to be verified.

You may say...no one care, but the first implementation of this solution may break within PureMVC with the Notifier sendNotification method in any Mediator/Proxy/Command subclass.

If this is really something that may interest people I could work on it, I like those problematic a lot.

As I told you recently I will work on the JavaScript port to transform the Employee Admin demo from Objs to define(). This could be a good occasion to try it so.

It may be a good idea to also port the standard version? What it is the status of this too?

If you really can't refrain you to use Prototype.js $super(),  better to rewrite the PureMVC JavaScript code itself, I've made a PureMVC port to Prototype.js (with 1.6.1 syntax but it has to work with 1.7.1 or make me a pull request) : http://www.tekool.net/blog/2011/01/19/puremvc-port-to-prototype-javascript-framework/

Another solution is to use TypeScript/Haxe to write JavaScript. I'm working on the TypeScript port of PureMVC, it finally allows us to write JavaScript code using simple and static typed syntax like super(). It still need some polish but it works like a charm.

I don't know for David who is responsible of the project, but in my opinion we better have to keep the prototype chain syntax to stay easily portable with more frameworks and languages.

Glad you're close to get your project working.

One solution I came up with was providing a way for each module to define the proxies it wants a reference to from the shell. When the shell creates the module, it can pass these proxies to the module. I could then treat these proxies almost as an external API that I could access from each module, perhaps having a proxy to abstract them from the module. I kinda feel like this type of a solution causes to much interdependence between a module and the shell. Any thoughts?

You're right, sharing a proxy reference between modules is not the good approach. But sharing data as you thought in the second part of your paragraph may be the right.

Your idea of asking via a notification a Proxy to send some data is the perfect one. To be sure to think modules and pipes communication the right way, just think modules as threads. If you share some data, this can be blocking, if you retrieve data synchronously it can be blocking, etc If we where in a multi-threaded environment this would be the solution of choice. It's really natural to think this way but as you supposed, requiring data of a Proxy, wait for it to send it to another one (even if it's hidden synchronous process in your game for the moment) can be quite long to write and somewhat quite long to process in a game environment that need speed.

A good intermediary solution to have something neat and at minimum cost is simply to use a common proxy class that each module will instantiate in its own environment (not the same instance shared). What you will share will be the reference to your data resource. Here in HTML 5 SQLite would be perfect, as it is thread safe (if I remember well). Then when some data is updated, the data module sends a notification to interested modules, interested modules so read the data. You can also use LocalStorage or even a simple reference to the same object in memory but you have to be careful with this solution, only the data module should have right to write to it. There's some smart things to do be sure to give write access only to the module that instantiate data first.

All of your choices seems the right ones to me!

I imagine creating a Command for each layout configuration which performs similar to above but using different size/position calculations.

Here starts the real application work, outside any architecture considerations. Just try to make your command reusable and maximize the use of Mediators methods for every operations that make view components specific operations like moves etc. that have no sense to make reusable in commands.

And sorry if I seem a little harsh in my answers, it's just that I'm really direct because English is not my native language.

this approach still has a problem that there is no central "manager" that holds any references to these components.

which is difficult when the command needs to refer to a list of view components that spans the entire stage, and it is born with no immediate access to any of them.

Both those problems has the same answer : command can decide what one or the other view component must do through mediators. This isn't a problem for a command to directly access the mediator reference and uses mediator methods designed to interact with one or a group of view components. This is always better to use integrated mediator notification support, but when the logic is reusable, complex, it is still better to use external commands that directly drive some important mediator behaviors.

So you have to maintain references into one or several mediator, even if each of those mediator only have reference to one or several MovieClip holding references to many other child MovieClip in it. As you say this is a problem of granularity. This is here only your choice, but having a look at demos on PureMVC Github you will have a good idea of what is acceptable and what isn't.

I'm not sure I agree with this. A view component can be responsible for its own contents, but it needn't/shouldn't be aware of anything outside of itself, such as where it is positioned on the screen.

You certainly misunderstood me. Re-read what I say. I told that the UI has to dispatch an event telling the Mediator that an element has been clicked or that it has been deployed. The mediator decide what to do here, the UI never know any lower level application component here.

I originally designed my application in this way, but then decided that the entire view creation should be separated out into a PrepareViewCommand.

Keep this design, this is the right one. It is always better to initialize view components and their mediators (even if you initialize only one mediator for several view components) in a command. This the PureMVC way to manage dependency injection, using Mediator constructors.

It sounds like you are saying that the application needs some kind of StageMediator.

No, a StageMediator to directly manage view components is not the best idea. It would be better to have a dedicated Mediator for your group of MovieClips. One or several Mediator which name indicate what it does. When your app will evolve, a StageMediator can't be reused easily as it lays to the Stage only.

This seems like a lot of logic to place inside a mediator which is, I thought, only supposed to catch events from the view and pass them back.

When I say that a mediator can manage more than one view component I of course don't mean to place the whole app logic into one mediator. A single mediator only have to manage a group of view components having their own logic. But avoid to manage UI that do not share any logic into the same mediator.

Decisions along the lines of "user has moved the mouse, so slide on the tools palette

This typically has to be managed by your view component itself, not even the mediator. The mediator will only receive the event saying that the user as clicked on some of the tools of the palette. At least, it can receive an event telling to refresh the layout when deployed for any reason (what can be one of the answer you search for your LayoutManager question) then the mediator sends the appropriate refresh Notification to all other mediators. This sort of things happens often and is the right way of handling UI events to re-dispatch them to others UI component.

Bill White made recently a port to JavaScript of a demo for PureMVC Pipes I made for Flex a long time ago : http://www.billdwhite.com/wordpress/?p=450

Thanks to him, you will have a good entry point to start with Pipes in JavaScript compared to Flash.

I think we already dicussed that on an another thread.

If I remember well, here, the problem is that we don't use any array methods. In fact it has to be re-typed to Object if Dictionnary isn't possible. I had too, in other ports I made, TypeScript included.

Indeed, you are right you're forced to use a main.js to order loading of each file. In fact my builds always use an XML file with Ant that order things for me before concate and compress them. I just forgotten that.

I'm using Backbone but with AMD too. If I need to use another compression solution that the one I use I will probably use near the same as yours, but using Require and its order plugin (I heard it is now included in Require directly).

Thanks for those infos.

I saw that you use a main.js file to define classpaths. Doesn't Dojo allows to declare classpath independently in each JavaScript file like Require.js does?

Like this(example given with the Controller class):

:

define(
    "org/puremvc/js/multicore/core/Controller" //<-- I mean adding this line
    [
        "dojo/_base/declare",
        "org/puremvc/js/multicore/core/View",
        "org/puremvc/js/multicore/patterns/observer/Observer"
    ],
    function(declare, View, Observer) {
       

I found this way of doing things really neat, as it allows to use a simple concatenation/compression tool to create a single file for the whole PureMVC framework without having to be dependent on a specific tool. Are you using any compression tool (provided by the Dojo framework I suppose) that understands your syntax, or is this recommended by CommonJS?

I will probably use your work in my current project to speed up the way I will integrate PureMVC into Backbone+Require with full AMD support.

Many thanx for this work, this is an excellent idea!

This will help anyone working with PureMVC and any AMD compatible library, not only Dojo. I'm currently working with Backbone + Require it would help in using PureMVC here too.


If you want to finish the work on the Pipes (with tests etc.) I think that you must contact Cliff directly to push a new project on Github. I think you're the first to port Pipes in JavaScript.