On Friday, May 2, 2014 3:51:03 PM UTC+2, Sebastien Diot wrote:
I have been trying to create an API, such that it would "look and feel" the same, both from GWT Java code, and from manually written JavaScript code. After much Googling, I came to gwt-exporter, which is the "universal answer" used, for anyone trying to do such a thing. So I gave it a try; unfortunately, things did not go well, as explained in this post to the gwt-exporter forum: Is there an ETA for GWT 2.6 support?
Having received no answer in 3 days, I have decided to try and do it "manually". I haven't had any success here either, but I think I have found the true problem: GWT just kills (some of) my code, because it thinks it's "not being used" (or perhaps, "inline" some methods, causing then to not be available anymore). In any case, the methods are *gone*. Looking for a solution to *that problem*, I get back to posts saying to use gwt-exporter there too. So I'm stuck in an infinite loop with no way out.
One critical difference to the "usual case", is that the manually written JavaScript code does not come from a JSNI call, but from an "external source", and so is *not available at compile time*. A compiler flag telling the compiler not to "prune" something would not be useful in this case; the flag/marker needs to be specific to classes and methods, instead of applying globally.
As I did not get any answer on the gwt-exporter forum in 3 days, and have therefore no way of knowing if, and when, gwt-exporter will be updated, I was hoping someone could point me to a solution that would provide the following benefits, even if it involves much boiler-plate GWT/JSNI code:
1) Instances of "marked" types can be created from JavaScript (in or out of JSNI, like from dynamically generated scripts, or scripts typed directly in the app UI), using the fully-qualified, non-obfuscated, Java class name. This should still work, if no code refers to that class, either from Java or JSNI.
2) All the public (at least) methods on the types selected in 1) will be available in JavaScript, using their simple, non-obfuscated, name (this probably preclude method overloading). It should work for both instance, and static methods. This should still work, if no code refers to that method, either from Java or JSNI.
To expose Java/GWT classes to JS, you have to wrap them, assigning there methods to Jav/GWT methods. E.g.
$wnd.com = $wnd.com || {};
$wnd.com.example = $wnd.com.example || {};
var _ = $wnd.com.example.MyClass = $entry(function(a, b) {
this._real = @com.example.MyClass:new(II)(a, b);
};
_.prototype.myMethod = $entry(function(a, b) {
this._real @ com.example.MyClass:myMethod(Lcom/example/MyClass;Z)(a._real, b);
});
Note how in myMethod I "unwrap" the Java/GWT MyClass instance from within the JS MyClass instance.
Methods that return a MyClass need to wrap it too (and ideally re-use the same JS wrapper as was already used for the same Java/GWT instance)
Because the class/constructor/method has to be referenced from JSNI to be exported, it won't be pruned by the compiler.
I don't know the internals of GWT-Exporter, but (I suppose) the goal is to free you of all this error-prone boilerplate.
3) (Optional) Same as methods, but for fields too.
Should be possible with custom getters and setters: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects#Defining_getters_and_setters
(apparently not supported in GWT-Exporter; probably it's not supported in IE8- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/get#Browser_compatibility)
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment