PureMVC Architects Lounge

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.

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>

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.

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>