[gwt-contrib] SerializableTypeOracleBuilder and GWT 2.7.0 RC1
Hi I am currently testing our application with GWT 2.7.0 RC1. During the upgrade I was reminded that we use a patched version of SerializableTypeOracleBuilder due to the long standing issue 7250 https://code.google.com/p/google-web-toolkit/issues/detail?id=7250 We had to patch 2.4, 2.5, 2.6 locally to make it work with our application. It is still an issue in GWT 2.7 RC1. I have updated the issue and the attached test case which demonstrates the problem and the fix Best regards Rene -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/54f0dca5-cc76-40a7-a970-cc097abc913b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] SerializableTypeOracleBuilder and GWT 2.7.0 RC1
This issue also affects gwt-storage: https://github.com/seanchenxi/gwt-storage/issues/4 For that case it wasn't very difficult to patch though: https://github.com/rdwallis/gwt-storage/commit/b8135545f3be843821a674fd6e01d784b4eeb0b2 although it does mean that you can't use the same dependency for 2.6.1 and 2.7 so I'm in favor of a deprecated method if that's possible. On Mon, Nov 3, 2014 at 10:13 AM, Rene Hangstrup Møller rhmol...@gmail.com wrote: Hi I am currently testing our application with GWT 2.7.0 RC1. During the upgrade I was reminded that we use a patched version of SerializableTypeOracleBuilder due to the long standing issue 7250 https://code.google.com/p/google-web-toolkit/issues/detail?id=7250 We had to patch 2.4, 2.5, 2.6 locally to make it work with our application. It is still an issue in GWT 2.7 RC1. I have updated the issue and the attached test case which demonstrates the problem and the fix Best regards Rene -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/54f0dca5-cc76-40a7-a970-cc097abc913b%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/54f0dca5-cc76-40a7-a970-cc097abc913b%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEqaEViBkiW1s0FJDQ%3Dqf2GmnH6FbHr0AtL%3DyZWG15pfR-UFQg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] JSInterop handle JavaScript get/set function with the same name
Consider the following JavaScript functions:
// get draggable flag
var draggable = node.draggable();
// enable drag and drop
node.draggable(true);
I do not see how I can modle them in JsInterop. The following would not
work:
@JsType(prototype = $wnd.Kinetic.Node)
public interface KNode {
void draggable(boolean value);
boolean draggable();
}
The former would not work because overlaying in Java based on return type
is forbidden. I also could not use @JsProperty because the getter and
setter are JavaScript functions.
Is there another way to deal with this in JsInterop?
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/862d9a24-3a07-4181-9cc0-17b7a26401ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] SDM in 2.7.0-rc1 doesn't support inclusion in 3rd party sites
Hi, I am writing a GWT generated JS script that is hosted by several sites. 2.7.0 introduced a breaking change in the code server. Until 2.7.0, I could test my code using a bookmarklet that injects the script into any site referring to SDM URLs, Now this is not possible anymore, I have opened an issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=8970 And also tested the suggested solution by compiling my own gwt-dev and codeserver. Is there any objections to the suggested flow? or better suggestions? (sadly it will take time for me to do the whole cla process) Tal -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/dba4f2de-9579-49db-8e42-9cdd1472867c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] SDM in 2.7.0-rc1 doesn't support inclusion in 3rd party sites
Can you take a look at this and let me know if this helps you out? https://github.com/mgwt/mgwt/wiki/SuperDevMode-with-PhoneGap On Mon, Nov 3, 2014 at 11:45 AM, Tal Shani tsh...@gmail.com wrote: Hi, I am writing a GWT generated JS script that is hosted by several sites. 2.7.0 introduced a breaking change in the code server. Until 2.7.0, I could test my code using a bookmarklet that injects the script into any site referring to SDM URLs, Now this is not possible anymore, I have opened an issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=8970 And also tested the suggested solution by compiling my own gwt-dev and codeserver. Is there any objections to the suggested flow? or better suggestions? (sadly it will take time for me to do the whole cla process) Tal -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/dba4f2de-9579-49db-8e42-9cdd1472867c%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/dba4f2de-9579-49db-8e42-9cdd1472867c%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiqN-FDMaRZKY8Kj%2BY2rc4nZ9%2BGaZc2ZtUW1J-H-vp7KdQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] JsInterop retrofit
Moving from interfaces to classes has other downsides. For example, you
can't avoid not generating a Java class/object, you can't have your own
super-class hierarchy and mark your class as supporting the same interface
as an external JS implemented one, the notion of JS objects implementing
a Java interface would seem strange if they implement the interface without
subclassing the prototype of the Java object with the annotation.
Take something like Elemental 2.0, which is likely to have several hundred,
maybe 1000 types for every conceivable WebUI, we do not want defineClass(),
class literals, castmaps, or java.lang.Object stuff set up for any of them.
With interfaces, it's clear there's no backing interface to compile. With
classes, we'd have to add some hackery to the compiler like if it's a
jstype, and it has zero implemented methods, and it's all native, and it
doesn't extend another class that has non-native methods, *then* we can
just drop it's class setup from the output.
Otherwise, for every single one of these you'll get massive bloat, and a
SDM compile of Elemental 2.0 would have a thousand stubbed out classes in
it.
On Sat Nov 01 2014 at 10:07:21 AM 'Goktug Gokdogan' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
(I will read respond to comments after the weekend)
On Sat, Nov 1, 2014 at 9:52 AM, Goktug Gokdogan gok...@google.com wrote:
There is also a third option.
User writes:
@JsType(prototype = Object)interface JsObject {
class prototype extends Prototype_JsObject {}
interface Static {
String[] keys(JsObject obj);
JsObject defineProperties(JsObject obj, JsObject props);
}
static Static getStatic() {
return new Static_JsObject();
}
static JsObject of(Object obj) {
return obj instanceof JsObject ? (JsObject) obj : null;
}
@JsConstructor
void constructor(String param);
boolean hasOwnProperty(String prop);
boolean isPrototypeOf(JsObject prop);
}
which generates:
@PrototypeOfJsType(JsObject.class)public class Prototype_JsObject {
JsObject constructor(String param) { return null;}
boolean hasOwnProperty(String prop) { return false; }
boolean isPrototypeOf(JsObject prop) { return false; }
}
public class Static_JsObject implements Static {
JsObject newInstance(String param) {
return js(new Object($0), param);
}
public String[] keys(JsObject obj) {
return js(Object.keys($0), obj);
};
public JsObject defineProperties(JsObject obj, JsObject props) {
...
}
}
And usage looks like:
MyObject extends JsObject.prototype {}
JsObject.getStatic().keys( ... );
JsObject.getStatic().newInstance( ... );
JsObject.of(new Object());
And it is perfectly testable.
On Sat, Nov 1, 2014 at 8:25 AM, Stephen Haberman
stephen.haber...@gmail.com wrote:
I will try to summarize my thought process and different options that
I have played with so that you could get a better understanding where
I'm coming from and I hope it will provide good documentation for
future.
Thanks for the email; I think the format was really useful.
One may argue that if we are committing to use some kind of DSL why
not use something else like IDL or xml etc. There are 3 main reasons
to use java + APT instead of others:
I really want to advocate APT, as I've used it and do generally like it,
but frankly it can be a huge PITA for Eclipse. See long-standing issues
e.g.:
https://github.com/square/dagger/issues/126
Granted, maybe someone can just fix Eclipse, but, in my experience, it
can really ruin the first impressions for a project (1000s of compile
errors due to missing generated code, and no hints that, btw, it's
because the APT was not on the classpath/didn't run).
All the cons are around the testability aspect. For JRE testing,
native methods are a headache. Also we no longer generate an interface
for static methods.
I know I just bitched about APT, but, just musing, what if the class
(with the native methods/etc.) was the DSL the user wrote, and then APT
just generated an interface from that?
This is basically what I'm doing by hand in tessell with writing
IsTextBox for TextBox, etc.
I admittedly am not an expert on JS prototype semantics, so am not sure
how this would handle statics/etc. But in testing I usually only care
about instance methods anyway...
A few years ago I spiked an APT processor to do this automatically:
https://github.com/stephenh/interfacegen
The oddity then becomes that the user is writing class JsObject, but
then if they want testable code, they need to code against the generated
IsJsObject interface. But perhaps that it's optional is a good thing,
e.g. you could come back and add the @GenInterface-type method later
if/when you wanted.
Anyway, I think I do like the last proposal, the class/native method
best.
Thanks, Goktug!
- Stephen
--
You received this message because you
Re: [gwt-contrib] SDM in 2.7.0-rc1 doesn't support inclusion in 3rd party sites
I have not used the js in the link you provided but.. reading it though i
understand now that i should have included .recompile.nocache.js in the
bookmarklet and not the one without the recompile.
so using the following bookmarklet
javascript:(function(wnd, src){var d = wnd.document; var s = d.createElement
('script');s.src=src; var scripts = d.getElementsByTagName('script');if(
scripts.length){scripts[0].parentNode.insertBefore(s, scripts[0])} else {var
head = d.getElementsByTagName('head')[0];head.appendChild(s);}})(window,
'http://localhost:9876/modulename/modulename.recompile.nocache.js');
does indeed solve the problem by loading directly the recompile file.
Thank You.
On Monday, November 3, 2014 5:07:43 PM UTC+2, Daniel Kurka wrote:
Can you take a look at this and let me know if this helps you out?
https://github.com/mgwt/mgwt/wiki/SuperDevMode-with-PhoneGap
On Mon, Nov 3, 2014 at 11:45 AM, Tal Shani tsh...@gmail.com javascript:
wrote:
Hi,
I am writing a GWT generated JS script that is hosted by several sites.
2.7.0 introduced a breaking change in the code server.
Until 2.7.0, I could test my code using a bookmarklet that injects the
script into any site referring to SDM URLs,
Now this is not possible anymore,
I have opened an issue:
https://code.google.com/p/google-web-toolkit/issues/detail?id=8970
And also tested the suggested solution by compiling my own gwt-dev and
codeserver.
Is there any objections to the suggested flow? or better suggestions?
(sadly it will take time for me to do the whole cla process)
Tal
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
javascript:.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/dba4f2de-9579-49db-8e42-9cdd1472867c%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/dba4f2de-9579-49db-8e42-9cdd1472867c%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
Google Germany GmbH
*Dienerstr. 12*
*80331 München*
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/694e6300-b466-436b-a83e-938f712d5cba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] JSInterop handle JavaScript get/set function with the same name
There is going to be a JsMethod to provide custom names to the method so
that you can name the method as abc() and map it to xyx() in the js.
But before that I didn't understand why it doesn't work out of the box. You
are not overloading based on return type; one of the methods has an
argument and the other one doesn't have any?
On Mon, Nov 3, 2014 at 1:13 AM, confile michael.gorsk...@googlemail.com
wrote:
Consider the following JavaScript functions:
// get draggable flag
var draggable = node.draggable();
// enable drag and drop
node.draggable(true);
I do not see how I can modle them in JsInterop. The following would not
work:
@JsType(prototype = $wnd.Kinetic.Node)
public interface KNode {
void draggable(boolean value);
boolean draggable();
}
The former would not work because overlaying in Java based on return type
is forbidden. I also could not use @JsProperty because the getter and
setter are JavaScript functions.
Is there another way to deal with this in JsInterop?
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/862d9a24-3a07-4181-9cc0-17b7a26401ee%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/862d9a24-3a07-4181-9cc0-17b7a26401ee%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA3vo-_YNhK6n265%2BPxKDof1UQOKnxq1dCtKFfeTzPj2AQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] JsInterop retrofit
On Sat, Nov 1, 2014 at 3:33 AM, Manuel Carrasco Moñino man...@apache.org
wrote:
After reading, and playing with some stub code based on these ideas, I
come to the conclusion than 'native' is almost perfect from the point of
view of a gwt developer.
We want pure java syntax and simplicity, and any other conventions like
DSLs or magic interface names, etc, could obscure the understanding
existing code, or trying to figure out how to implement something.
For java developers 'native' means that the platform knows how to deal
with this method, and in the case of gwt this is true and intuitive,
meaning that 'this is native because it's implemented natively in JS'.
The compiler ability to automatically resolve native methods, could be
very useful not only for JsInterop but for many other cases where we use
them.
Hence any getter or setter could be automatically written by the compiler
if it does not have the jsni fragment. For instance in
c.g.g.d.c.StyleElement we could get rid of all of the jsni fragments and
just write methods declaration
public final native void setCssText(String cssText);
If the compiler does this, we could save thousands of line of code in jsni
fragments in the gwt core, also in elemental, and in several other 3 party
libraries.
Even, we could have an annotation to deal with simple JSNI code instead of
using c++ comment blocks to change the default implementation:
@Jsni(return $doc.head || $doc.getElementsByTagName('head')[0])
public final native void getHead();
I don't have any intention to go beyond what java supports in terms of
native methods. The JSNI annotation just add another obscure way of doing
what could do with js() statements.
Also it would be nice if the compiler is able to deal directly with type
conversion and it is able to box returned values: java arrays to jsArrays,
js numbers to java types, etc. This will make gwt developer experience
better.
This is in the plans and we are planning to support something like
JsConvert (see the doc).
Related with testing, I think that because we already use the GWTTestCase
to run JRE tests (returning module null), it should be not difficult to
modify it and return proxies of classes implementing native methods ant
throwing sensible messages to the user telling what methods are used, etc.
Coming back to JsInterop, I agree that native methods is an easy solution,
probably not so difficult to implement, and definitively solves many
problems like inheritance, static methods, constructors, etc.
On Sat, Nov 1, 2014 at 6:52 AM, 'Goktug Gokdogan' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
I finally had some time to think about JsInterop and how to abstract
browser APIs.
I will try to summarize my thought process and different options that I
have played with so that you could get a better understanding where I'm
coming from and I hope it will provide good documentation for future.
So I started by playing with the static functions, constructors and how
to represent that with the current JsInterop semantics.
First I started with the original approach: use @JsType on an interface
and use some simple conventions to generate the rest:
@JsType(prototype = Object)interface JsObject extends Auto_JsObject {
static JsObject of(Object obj) {
return obj instanceof JsObject ? (JsObject) obj : null;
}
interface Static {
String[] keys(JsObject obj);
JsObject defineProperties(JsObject obj, JsObject props);
}
interface constructors {
void constructor(String param);
}
boolean hasOwnProperty(String prop);
boolean isPrototypeOf(JsObject prop);
}
then with the annotation processor following code will be generated:
interface Auto_JsObject {
public static JsObject newInstance(String param) {
return js(new Object($0), param);
}
public static String[] keys(JsObject obj) {
return js(Object.keys($0), obj);
}
public static JsObject defineProperties(JsObject obj, JsObject props) {
...
}
@PrototypeOfJsType(JsObject.class)
public static class prototype {
JsObject constructor(String param) { return null}
boolean hasOwnProperty(String prop) { return false; };
boolean isPrototypeOf(JsObject prop) { return false; };
}
}
And it looks like following when used:
MyObject extends JsObject.prototype {}
JsObject.keys( ... );
JsObject.newInstance( ... );
JsObject.of(new Object());
One of the advantages of this is; I can additionally generate a special
method named statics() that returns an instance of JsObject.Static where
we forward all calls to the static methods. This is pretty useful for
people who care about pure unit testing.
Although this solution is not ideal due to need for extending a separate
class (i.e. JsObject.prototype), it looks reasonably good at first sight.
But there is one
Re: [gwt-contrib] JsInterop retrofit
On Sat, Nov 1, 2014 at 8:25 AM, Stephen Haberman stephen.haber...@gmail.com wrote: I will try to summarize my thought process and different options that I have played with so that you could get a better understanding where I'm coming from and I hope it will provide good documentation for future. Thanks for the email; I think the format was really useful. One may argue that if we are committing to use some kind of DSL why not use something else like IDL or xml etc. There are 3 main reasons to use java + APT instead of others: I really want to advocate APT, as I've used it and do generally like it, but frankly it can be a huge PITA for Eclipse. See long-standing issues e.g.: https://github.com/square/dagger/issues/126 Granted, maybe someone can just fix Eclipse, but, in my experience, it can really ruin the first impressions for a project (1000s of compile errors due to missing generated code, and no hints that, btw, it's because the APT was not on the classpath/didn't run). GWT already requires kind of special setup in Eclipse so I think we are in better shape. Also we will need APT's regardless of this feature as that will be the only way for code generation in the long run. All the cons are around the testability aspect. For JRE testing, native methods are a headache. Also we no longer generate an interface for static methods. I know I just bitched about APT, but, just musing, what if the class (with the native methods/etc.) was the DSL the user wrote, and then APT just generated an interface from that? This is basically what I'm doing by hand in tessell with writing IsTextBox for TextBox, etc. I admittedly am not an expert on JS prototype semantics, so am not sure how this would handle statics/etc. But in testing I usually only care about instance methods anyway... A few years ago I spiked an APT processor to do this automatically: https://github.com/stephenh/interfacegen The oddity then becomes that the user is writing class JsObject, but then if they want testable code, they need to code against the generated IsJsObject interface. But perhaps that it's optional is a good thing, e.g. you could come back and add the @GenInterface-type method later if/when you wanted. Anyway, I think I do like the last proposal, the class/native method best. Thanks, Goktug! - Stephen -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/20141101102535.45715a48%40sh9 . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0qKf24J6SGHO8vA%2B6EiCw3FZyygeRJjqYrw9RhC%3DdN8w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] JsInterop retrofit
I think I didn't understand some of your concerns. Let's meet some time
this week to flush out what all of this means and the implications.
On Mon, Nov 3, 2014 at 8:45 AM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Moving from interfaces to classes has other downsides. For example, you
can't avoid not generating a Java class/object, you can't have your own
super-class hierarchy and mark your class as supporting the same interface
as an external JS implemented one, the notion of JS objects implementing
a Java interface would seem strange if they implement the interface without
subclassing the prototype of the Java object with the annotation.
Take something like Elemental 2.0, which is likely to have several
hundred, maybe 1000 types for every conceivable WebUI, we do not want
defineClass(), class literals, castmaps, or java.lang.Object stuff set up
for any of them. With interfaces, it's clear there's no backing interface
to compile. With classes, we'd have to add some hackery to the compiler
like if it's a jstype, and it has zero implemented methods, and it's all
native, and it doesn't extend another class that has non-native methods,
*then* we can just drop it's class setup from the output.
Otherwise, for every single one of these you'll get massive bloat, and a
SDM compile of Elemental 2.0 would have a thousand stubbed out classes in
it.
On Sat Nov 01 2014 at 10:07:21 AM 'Goktug Gokdogan' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
(I will read respond to comments after the weekend)
On Sat, Nov 1, 2014 at 9:52 AM, Goktug Gokdogan gok...@google.com
wrote:
There is also a third option.
User writes:
@JsType(prototype = Object)interface JsObject {
class prototype extends Prototype_JsObject {}
interface Static {
String[] keys(JsObject obj);
JsObject defineProperties(JsObject obj, JsObject props);
}
static Static getStatic() {
return new Static_JsObject();
}
static JsObject of(Object obj) {
return obj instanceof JsObject ? (JsObject) obj : null;
}
@JsConstructor
void constructor(String param);
boolean hasOwnProperty(String prop);
boolean isPrototypeOf(JsObject prop);
}
which generates:
@PrototypeOfJsType(JsObject.class)public class Prototype_JsObject {
JsObject constructor(String param) { return null;}
boolean hasOwnProperty(String prop) { return false; }
boolean isPrototypeOf(JsObject prop) { return false; }
}
public class Static_JsObject implements Static {
JsObject newInstance(String param) {
return js(new Object($0), param);
}
public String[] keys(JsObject obj) {
return js(Object.keys($0), obj);
};
public JsObject defineProperties(JsObject obj, JsObject props) {
...
}
}
And usage looks like:
MyObject extends JsObject.prototype {}
JsObject.getStatic().keys( ... );
JsObject.getStatic().newInstance( ... );
JsObject.of(new Object());
And it is perfectly testable.
On Sat, Nov 1, 2014 at 8:25 AM, Stephen Haberman
stephen.haber...@gmail.com wrote:
I will try to summarize my thought process and different options that
I have played with so that you could get a better understanding where
I'm coming from and I hope it will provide good documentation for
future.
Thanks for the email; I think the format was really useful.
One may argue that if we are committing to use some kind of DSL why
not use something else like IDL or xml etc. There are 3 main reasons
to use java + APT instead of others:
I really want to advocate APT, as I've used it and do generally like it,
but frankly it can be a huge PITA for Eclipse. See long-standing issues
e.g.:
https://github.com/square/dagger/issues/126
Granted, maybe someone can just fix Eclipse, but, in my experience, it
can really ruin the first impressions for a project (1000s of compile
errors due to missing generated code, and no hints that, btw, it's
because the APT was not on the classpath/didn't run).
All the cons are around the testability aspect. For JRE testing,
native methods are a headache. Also we no longer generate an interface
for static methods.
I know I just bitched about APT, but, just musing, what if the class
(with the native methods/etc.) was the DSL the user wrote, and then APT
just generated an interface from that?
This is basically what I'm doing by hand in tessell with writing
IsTextBox for TextBox, etc.
I admittedly am not an expert on JS prototype semantics, so am not sure
how this would handle statics/etc. But in testing I usually only care
about instance methods anyway...
A few years ago I spiked an APT processor to do this automatically:
https://github.com/stephenh/interfacegen
The oddity then becomes that the user is writing class JsObject, but
then if they want testable code, they need to code against the generated
IsJsObject interface. But
Re: [gwt-contrib] JsInterop retrofit
An additional pros / cons about getting rid of JsObject.prototype:
Not having JsObject.prototype fixes the symmetry problem between SDK and
user code. For example earlier, when you extend Element you need to extend
Element.prototype but if the custom element is implemented in java side,
then you need to extend MyJavaElement without the .prototype.
The counter argument could be; extending .prototype makes it obvious that
your are extending a javascript object (which has its own pros and cons
(breaks encapsulation vs one might want to know this for some reason that I
couldn't find yet)).
On Mon, Nov 3, 2014 at 12:27 PM, Goktug Gokdogan gok...@google.com wrote:
I think I didn't understand some of your concerns. Let's meet some time
this week to flush out what all of this means and the implications.
On Mon, Nov 3, 2014 at 8:45 AM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Moving from interfaces to classes has other downsides. For example, you
can't avoid not generating a Java class/object, you can't have your own
super-class hierarchy and mark your class as supporting the same interface
as an external JS implemented one, the notion of JS objects implementing
a Java interface would seem strange if they implement the interface without
subclassing the prototype of the Java object with the annotation.
Take something like Elemental 2.0, which is likely to have several
hundred, maybe 1000 types for every conceivable WebUI, we do not want
defineClass(), class literals, castmaps, or java.lang.Object stuff set up
for any of them. With interfaces, it's clear there's no backing interface
to compile. With classes, we'd have to add some hackery to the compiler
like if it's a jstype, and it has zero implemented methods, and it's all
native, and it doesn't extend another class that has non-native methods,
*then* we can just drop it's class setup from the output.
Otherwise, for every single one of these you'll get massive bloat, and a
SDM compile of Elemental 2.0 would have a thousand stubbed out classes in
it.
On Sat Nov 01 2014 at 10:07:21 AM 'Goktug Gokdogan' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
(I will read respond to comments after the weekend)
On Sat, Nov 1, 2014 at 9:52 AM, Goktug Gokdogan gok...@google.com
wrote:
There is also a third option.
User writes:
@JsType(prototype = Object)interface JsObject {
class prototype extends Prototype_JsObject {}
interface Static {
String[] keys(JsObject obj);
JsObject defineProperties(JsObject obj, JsObject props);
}
static Static getStatic() {
return new Static_JsObject();
}
static JsObject of(Object obj) {
return obj instanceof JsObject ? (JsObject) obj : null;
}
@JsConstructor
void constructor(String param);
boolean hasOwnProperty(String prop);
boolean isPrototypeOf(JsObject prop);
}
which generates:
@PrototypeOfJsType(JsObject.class)public class Prototype_JsObject {
JsObject constructor(String param) { return null;}
boolean hasOwnProperty(String prop) { return false; }
boolean isPrototypeOf(JsObject prop) { return false; }
}
public class Static_JsObject implements Static {
JsObject newInstance(String param) {
return js(new Object($0), param);
}
public String[] keys(JsObject obj) {
return js(Object.keys($0), obj);
};
public JsObject defineProperties(JsObject obj, JsObject props) {
...
}
}
And usage looks like:
MyObject extends JsObject.prototype {}
JsObject.getStatic().keys( ... );
JsObject.getStatic().newInstance( ... );
JsObject.of(new Object());
And it is perfectly testable.
On Sat, Nov 1, 2014 at 8:25 AM, Stephen Haberman
stephen.haber...@gmail.com wrote:
I will try to summarize my thought process and different options that
I have played with so that you could get a better understanding where
I'm coming from and I hope it will provide good documentation for
future.
Thanks for the email; I think the format was really useful.
One may argue that if we are committing to use some kind of DSL why
not use something else like IDL or xml etc. There are 3 main reasons
to use java + APT instead of others:
I really want to advocate APT, as I've used it and do generally like
it,
but frankly it can be a huge PITA for Eclipse. See long-standing issues
e.g.:
https://github.com/square/dagger/issues/126
Granted, maybe someone can just fix Eclipse, but, in my experience, it
can really ruin the first impressions for a project (1000s of compile
errors due to missing generated code, and no hints that, btw, it's
because the APT was not on the classpath/didn't run).
All the cons are around the testability aspect. For JRE testing,
native methods are a headache. Also we no longer generate an
interface
for static methods.
I know I just bitched about APT, but, just musing, what if the
Re: [gwt-contrib] JSInterop handle JavaScript get/set function with the same name
Will the custom names method be part of the GWT 2.7 release? That would be
great. I think with this method you can handle nearly everything with
JsInterop.
When I tried the above JsType as Interface I get the following error:
GET /recompile/mobilePhoneGapIOS
Job test.mobile.MobilePhoneGapIOS_1_6
starting job: test.mobile.MobilePhoneGapIOS_1_6
binding: mgwt.density=xhigh
Compiling module test.mobile.MobilePhoneGapIOS
Ignored 1 unit with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all
errors.
Tracing compile failure path for type
'org.test.kinetic.client.KNode'
[ERROR] Errors in
'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/KNode.java'
[ERROR] Line 22: JsType methods cannot overload another
method.
[ERROR] Errors in
'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/events/KNodeEventCallbackJSO.java'
[ERROR] org.test.kinetic.client.events.KNodeEvent cannot be
resolved to a type
[ERROR] Errors in
'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/events/KNodeEvent.java'
[ERROR] org.test.kinetic.client.KShape cannot be resolved to
a type
[ERROR] Errors in
'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/KShape.java'
[ERROR] org.test.kinetic.client.KNode cannot be resolved to
a type
Computing all possible rebind results for
'test.mobile.client.app.photoEditor.PhotoEditor.Resources'
Rebinding
test.mobile.client.app.photoEditor.PhotoEditor.Resources
Checking rule generate-with
class='com.googlecode.gwtphonegap.server.log.rebind.PhoneGapLogThresholdGenerator'/
[ERROR] Hint: Check the inheritance chain from your
module; it may not be inheriting a required module or a module may not be
adding its source path entries properly
[ERROR] Errors in
'test/mobile/client/app/photoEditor/PhotoEditor.java'
[ERROR] Line 67: Failed to resolve
'test.mobile.client.app.photoEditor.PhotoEditor.Resources' via deferred
binding
Unification traversed 510 fields and methods and 343 types. 15 are
considered part of the current module and 15 had all of their fields and
methods traversed.
[WARN] Some stale types ([org.test.kinetic.client.KNode]) were not
reprocessed as was expected. This is either a compiler bug or a Generator
has legitimately stopped creating these types.
[ERROR] Compiler returned false
[WARN] recompile failed
[WARN] continuing to serve previous version
Michael
Am Montag, 3. November 2014 20:00:29 UTC+1 schrieb Goktug Gokdogan:
There is going to be a JsMethod to provide custom names to the method so
that you can name the method as abc() and map it to xyx() in the js.
But before that I didn't understand why it doesn't work out of the box.
You are not overloading based on return type; one of the methods has an
argument and the other one doesn't have any?
On Mon, Nov 3, 2014 at 1:13 AM, confile michael@googlemail.com
javascript: wrote:
Consider the following JavaScript functions:
// get draggable flag
var draggable = node.draggable();
// enable drag and drop
node.draggable(true);
I do not see how I can modle them in JsInterop. The following would not
work:
@JsType(prototype = $wnd.Kinetic.Node)
public interface KNode {
void draggable(boolean value);
boolean draggable();
}
The former would not work because overlaying in Java based on return type
is forbidden. I also could not use @JsProperty because the getter and
setter are JavaScript functions.
Is there another way to deal with this in JsInterop?
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
javascript:.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/862d9a24-3a07-4181-9cc0-17b7a26401ee%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/862d9a24-3a07-4181-9cc0-17b7a26401ee%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/6dfbc8e7-9997-4918-aeb3-befea70bd9d2%40googlegroups.com.
For more options, visit
Re: [gwt-contrib] JSInterop handle JavaScript get/set function with the same name
Method overloading is supposed to be ok if there is no prototype is given,
however in your case prototype is provided hence even if we fix it, it will
not work for your case.
There two ways to cover your use case here. One is making var-args work (if
it is not already working) so that you can do something like following to
cover both in single method:
boolean draggable(Object... args)
You can give it a try and see if works (but I doubt it will work right now).
The second way is to support overloading. We already decided to support
overloading at least based on number of arguments and this scenario is
covered under that.
However we don't have an ETA for this and 2.7 is already at RC1 so you need
to wait for the next release.
On Mon, Nov 3, 2014 at 1:27 PM, confile michael.gorsk...@googlemail.com
wrote:
Will the custom names method be part of the GWT 2.7 release? That would be
great. I think with this method you can handle nearly everything with
JsInterop.
When I tried the above JsType as Interface I get the following error:
GET /recompile/mobilePhoneGapIOS
Job test.mobile.MobilePhoneGapIOS_1_6
starting job: test.mobile.MobilePhoneGapIOS_1_6
binding: mgwt.density=xhigh
Compiling module test.mobile.MobilePhoneGapIOS
Ignored 1 unit with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all
errors.
Tracing compile failure path for type
'org.test.kinetic.client.KNode'
[ERROR] Errors in
'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/KNode.java'
[ERROR] Line 22: JsType methods cannot overload another
method.
[ERROR] Errors in
'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/events/KNodeEventCallbackJSO.java'
[ERROR] org.test.kinetic.client.events.KNodeEvent cannot be
resolved to a type
[ERROR] Errors in
'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/events/KNodeEvent.java'
[ERROR] org.test.kinetic.client.KShape cannot be resolved
to a type
[ERROR] Errors in
'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/KShape.java'
[ERROR] org.test.kinetic.client.KNode cannot be resolved to
a type
Computing all possible rebind results for
'test.mobile.client.app.photoEditor.PhotoEditor.Resources'
Rebinding
test.mobile.client.app.photoEditor.PhotoEditor.Resources
Checking rule generate-with
class='com.googlecode.gwtphonegap.server.log.rebind.PhoneGapLogThresholdGenerator'/
[ERROR] Hint: Check the inheritance chain from your
module; it may not be inheriting a required module or a module may not be
adding its source path entries properly
[ERROR] Errors in
'test/mobile/client/app/photoEditor/PhotoEditor.java'
[ERROR] Line 67: Failed to resolve
'test.mobile.client.app.photoEditor.PhotoEditor.Resources' via deferred
binding
Unification traversed 510 fields and methods and 343 types. 15
are considered part of the current module and 15 had all of their fields
and methods traversed.
[WARN] Some stale types ([org.test.kinetic.client.KNode]) were
not reprocessed as was expected. This is either a compiler bug or a
Generator has legitimately stopped creating these types.
[ERROR] Compiler returned false
[WARN] recompile failed
[WARN] continuing to serve previous version
Michael
Am Montag, 3. November 2014 20:00:29 UTC+1 schrieb Goktug Gokdogan:
There is going to be a JsMethod to provide custom names to the method so
that you can name the method as abc() and map it to xyx() in the js.
But before that I didn't understand why it doesn't work out of the box.
You are not overloading based on return type; one of the methods has an
argument and the other one doesn't have any?
On Mon, Nov 3, 2014 at 1:13 AM, confile michael@googlemail.com
wrote:
Consider the following JavaScript functions:
// get draggable flag
var draggable = node.draggable();
// enable drag and drop
node.draggable(true);
I do not see how I can modle them in JsInterop. The following would not
work:
@JsType(prototype = $wnd.Kinetic.Node)
public interface KNode {
void draggable(boolean value);
boolean draggable();
}
The former would not work because overlaying in Java based on return
type is forbidden. I also could not use @JsProperty because the getter and
setter are JavaScript functions.
Is there another way to deal with this in JsInterop?
--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on
