So, again, I updated Dart editor to the latest as of today, and in the puremvc-dart-multicore-framework project, in the pubspec.yaml,

I CHANGED

dependencies:
   unittest:
      sdk:test

TO

dependencies:
   unittest:any

AND NOW

When I do pub install,

I GET

Could not find package "unittest 0.0.0-r14669" at http://pub.dartlang.org.

Then, from the root of the puremvc-dart-multicore-framework project, I tried removing the packages in case the old packages were in the way somehow:

rm -rf packages
rm -rf test/packages


So this is just a plain project without dependencies installed and from terminal, still, when I do pub install,

I GET

Could not find package "unittest 0.0.0-r14669" at http://pub.dartlang.org.

It seems as if something in the way the Unit Test project is setup at pub.dartlang.org.

This is everything I went through before. Seth had said to create a new app and add unittest and see if that works. And I did, and it did. So.... what gives, Dart?

More to come...

Alright, I think I know what this is about. I saw a post about this on G+ and tried changing the dependencies, but the latest Dart editor at the time was not pleased. I told Seth about it and he said that i should try a new project and see if I get the same issue. Unfortunately, holiday ups and downs got in the way of completing that task. I'll see if I change the deps today if it works. More on this shortly...

-=Cliff>

I'm going to move this to the appropriate board. Don't have an answer at the moment, but it'll be more likely that someone who does will see it...

-=Cliff>

This port has only recently shown up. The author may be working on something, but I'm not sure. Hoping he'll be able to weigh in on this.

Apparently reflection is not possible in GWT without jumping through hoops:
http://stackoverflow.com/questions/4195233/can-you-use-java-reflection-api-in-gwt-client
https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/64lJJ6GHa6E

For the time being, carman23, it looks like the answer (as awful is it seems) is that in the Standard version, you have to send in an instance of the command and make sure that it doesn't do anything stateful (i.e. make sure to clear your variables each time execute is called).

In the MultiCore port (which this demo should get ported to) you could send the class reference.

The very oldest version of the framework did pass class references. Then it was completely replaced with the GWT version, and this demo didn't get updated.

This difference is untenable, and we'll have to address it, if I have to dive back into Java myself to do it. It has been many years, but it'd be a matter of tooling up again for it. Not a bad exercise.

The problem is just what to do, and I think it would be reasonable to move GWT to its own port. It can't be claimed to be Java without reflection. Java is Java and GWT is GWT. Therefore it would become the GWT standard port and we'd backport the Java MultiCore to Standard and just strip it of the multicore aspect.

That is a tangle in terms of people who may be using the port, but moving it to a branch is not something that works well either for the long term.

-=Cliff>

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.

I was unhappy at the idea of reusing an ICommand instance, because it is counter to the original design philosophy and thus the same advice cannot be applied across platforms, which is bad.

I think Frederic is right in thinking of just back-porting the MultiCore version to Standard so they operate the same, except that may mean inability to use in GWT. Frederic, could you look at whether GWT can pass class references around?

-=Cliff>

If you have a GitHub account, post your issue here:
https://github.com/PureMVC/puremvc-typescript-multicore-framework/issues

Even better, if you have a suggested fix, submit a pull request:
https://github.com/PureMVC/puremvc-typescript-multicore-framework/pulls

Otherwise feel free to post about it in this board.
-=Cliff>

If you have a GitHub account, post your issue here:
https://github.com/PureMVC/puremvc-typescript-standard-framework/issues

Even better, if you have a suggested fix, submit a pull request:
https://github.com/PureMVC/puremvc-typescript-standard-framework/pulls

Otherwise feel free to post about it in this board.
-=Cliff>

This demo illustrates techniques for performing routine maintenance operations in a PureMVC-based TypeScript / jQuery application. Require.js is used for module loading.

The demo is located here: https://github.com/PureMVC/puremvc-typescript-demo-employeeadmin/wiki

If you have a GitHub account, post any issues here:
https://github.com/PureMVC/puremvc-typescript-demo-employeeadmin/issues

Even better, if you have a suggested fix, submit a pull request:
https://github.com/PureMVC/puremvc-typescript-demo-employeeadmin/pulls

The author is Frederic Saunier.

The project is located here: https://github.com/PureMVC/puremvc-typescript-multicore-framework/wiki

If possible, please use GitHub to report issues.

The Project Owner is:
Frederic Saunier <frederic.saunier@puremvc.org>

-=Cliff>

The project is located here: https://github.com/PureMVC/puremvc-typescript-standard-framework/wiki

If possible, please use GitHub to report issues.

The Project Owner is:
Frederic Saunier <frederic.saunier@puremvc.org>

-=Cliff>

Do you have some demo stuff working in a repo somewhere that we can review? I'm interested in helping to figure out how that might work as well.

I am working to get Bill White's JS Pipes utility ready for primetime, and I'm wondering if a separate core that has this stuff in it might be a managable approach. You'd send PipeMessages to it and it would... (do things?).

But I'd like to see what sort of code and declarations we're pushing around before making any concrete suggestions.

can have a look into porting the John Resig solution into PureMVC. I have studied those kind of solution

That would be really great, I'd love to see it. The problem you outline with the ultimate superclass methods not being reachable if the intervening subclasses fail to override has to be handled, and I'm sure it will complicate matters quite a bit.

I've been working recently with getting Bill White's pipes port ready (moving to puremvc.pipes.* rather than org.puremvc.js.multicore.utilities.pipes.* and fixing bugs).  I ran into the inheritance problem there. And another issue is that the current documentation tool (jsduck) can't follow the PureMVC define() hierarchy. Therefore I've chosen to work with his native JS prototype version for the official repo.

Sounds cool, and let us know when the game is released.

Also, just remember if you are in a situation where you are wondering how to share a Proxy between modules, it is an indication that you really need to refactor that proxy out into a core of its own and talk to it via messages.

Ideally, modules know nothing more than a protocol for communications with other modules and only data and view components are shared or passed between modules.

Why is that?

Imagine a Facebook API Proxy. Lets say you have one module that fetches media from the user's album and does something with it. Also, you have another module that can make posts to the user's timeline. So, they both need either a reference to the FacebookProxy, or separate instances, right? NO!

Lets say the FacebookProxy has some changes with regard to the way functions have to be called, perhaps as a result of a change at Facebook, or perhaps just because the FacebookProxy is in flux as required features of the API are added.

When the FacebookProxy changes in such a way that its callers have to be changed, now you have more than one affected module that uses it. The more callers, the larger the potential impact of any given change.

However, if you put that FacebookProxy into a separate core, and create a protocol for talking to it via messages, you limit the impact of changes. JavaScript doesn't have interfaces, but a message protocol can serve the same goal.

The PrepareViewCommand instantiates the stageView.
The stageView instantiates the top-level components.
The top-level components instantiate whatever they want, they must take care of themselves and their children.
The PrepareViewCommand also instantiates a stageMediator to mediate the stageView, and likely further mediators for the top-level components (via references exposed by the stageView).

So far, so good (I hope).

Yep.

So what if we want a mediator for a view component which is nested several levels deep into the hierarchy?
The stageView doesn't know about this component, it knows only of the top-level components.

Good question...

1. Allow the PrepareViewCommand to "reach in" and grab a reference to the view component by descending through the view levels via exposed references at each level (bad OOP!)

This isn't the best option, and the deeper it has to reach the more egregious a breach it is. If you're rushing through a prototype, this might be acceptable, but you'd never do it with production code.

2. Component fires an "I exist, mediate me!" event which is caught by the stageMediator which then creates the mediator for it (slightly bad OOP! stageView *still* needs to know what the component is in order to create the correct mediator for it. Besides, at creation time the stageMediator doesn't yet exist)

In Flex, where component creation may be deferred, this sort of handling is necessary. Well, you'd really not let it bubble all the way to the stage mediator, but to the mediator of the parent component. For instance, if the User Form instantiated a different subsection depending on the type of user, then the UserFormMediator would be in charge of mediating that subsection. This isolates the knowledge of what mediator to use for which component in the closest mediator to the action.

Another variation on this theme is to let the 'MediateMe!' event bubble all the top, and have the top level mediator catch it and then send it off in a notification to be handled by a command. It can have a switch that looks at the type of the component, (or a property from an interface all components expose), and for each case, mediates the event target with a given mediator. This works well, but it still isn't optimal to have commands handling view components, although it is acceptable from MVC perspective, in practice it's not so hot.

3. Insist that only the top-level components are mediated and decide that this is exactly the right level of granularity for mediation. Hmmm... would work, but the tail is wagging the dog here.

Nah.

Usually, if a mediated view component has a child that needs to be mediated, and that child exists at the time the view component is being mediated, then we have the mediator of the view component register the mediator for the child.

In fact, if the whole view exists by the time PrepareViewCommand is run, you can just mediate the StageView, and have the StageViewMediator (in its onRegister() method) register the immediate children. Then mediators can mediate the children of their own view components, ad infinitum.

This is really the most proper way to do it, because a Mediator is the only designated actor in the system that should 'know' a view component, and therefore have access to its direct children to mediate.

-=Cliff>