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.
3) (Optional) Same as methods, but for fields too.
The "end goal" is to allow users some limited ability to "customize" the application by "injecting user scripts" into it.
I would be grateful for any help.
Regards,
Sebastien Diot
-- 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.
3) (Optional) Same as methods, but for fields too.
The "end goal" is to allow users some limited ability to "customize" the application by "injecting user scripts" into it.
I would be grateful for any help.
Regards,
Sebastien Diot
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