[gwt-contrib] Minor thing with Elemental 2 DomGlobal.requestAnimationFrame
Hi,
I found a small annoyance with DomGlobal.requestAnimationFrame in that you
have to supply a function which returns an Object.
DomGlobal.requestAnimationFrame(event -> {
myPresenter.loadContent();
return null;
});
I'd like to be able to pass a void method, where should I report this?
Anders
--
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/d6469b0d-43a1-4ea3-9292-7a07d7b73dd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: JsInterop & collections
In short I would like JS arrays to be visible in GWT as a List and objects parsed from JSON also as a Map. Maybe I'll try one more time to explain what we have. We share model between server and GWT in form of java interfaces. Those interfaces are declared as return types of Jersey services, which serve instances of those interfaces. GWT uses exactly the same interfaces and handles them with AutoBeans. It works quite well, but there are two issues. First issue is that occasionally we need to pass some part of the data to JS. More often than not, it is a list or contains a list. As a result, we need to repackage it, as GWT objects are not understood by JS. Now we plan to leverage more JS, so we will have to deal with this problem more often. Second issue is that AutoBeans turned out to be inefficient in larger scale, as the generated code is roughly 50% of our written code. So, we came up with following idea: let’s keep shared interfaces, just annotate them with @JsType(native=true). Then use regular browser’s JSON parser and cast parsed object into model interface with @JsType. It works like charm for simple objects, but not for collections - List is being parsed as an JS array; Map is nothing else but just regular object. Dropping support for java collections, would be very expensive, and would require heavy refactoring, as the app is big (over 0.5 million Java lines in GWT + affected server parts). I thought there could be a way to tell JsInterop that specific field is backed by a plain array (or list) and an object (for map). I believe it was in plans with @JsConvert – see slides 67 – 69. https://docs.google.com/file/d/0ByS1wxINeBWjeGYxbkJpamxFZ28/edit Marcin On Tue, May 9, 2017 at 12:16 AM, 'Goktug Gokdogan' via GWT Contributors < google-web-toolkit-contributors@googlegroups.com> wrote: > What do you mean exactly by "collection support in JsInterop"? From you > description I only understand that you want to keep using java collection > API for existing & server side code. > If you want use your JavaScript array/map instance from Java, you need an > adaptor; doesn't matter who provides. And sure you can do it yourself. > If you want use you Java collection from JavaScript, we already > jsinterop-enabled many collection APIs. > > On Mon, May 8, 2017 at 1:44 PM, Manuel Carrasco Moñino > wrote: > >> If in your model is enough to have Collections/Lists based on ArrayList >> you can easily convert from JsArrays to ArrayLists and vice-versa by using >> a bit of JSNI since the ArrayList implementation in GWT relies on a >> javascript array. >> >> Take a look to this code used in the gwt-polymer-elements library (put >> attention to asList and asArrayList methods) >> >> https://github.com/manolo/gwt-api-generator/blob/master/lib/ >> com/vaadin/polymer/Polymer.java#L522 >> >> - Manolo >> >> >> On Mon, May 8, 2017 at 10:27 PM, Marcin Okraszewski >> wrote: >> >>> Basically what we need it for is REST. Currently we use AutoBeans, but >>> we want to change it because we need to pass the model to JS too; secondly >>> AutoBeans generate a lot of code. We would like to still preserve shared >>> model with the server. So, JsInterop seems the most natural choice, except >>> it doesn't support collections. We mostly need List and Map. Switching to >>> JsInterop with replacing Lists with some JS array view would be quite an >>> effort. It would introduce that into our server logic too (by the shared >>> model). And and you could even use Java's for each loop, as native JsType >>> cannot extend non-JsType interfaces, so it could not extend Iterable (of >>> course adapter could be instantiated for every list you want to iterate). >>> Same for streams. >>> >>> Therefore we look for collection support in JsInterop, which was planned >>> for "phase 2". If that was in our reach, we could help in getting it. >>> >>> Marcin >>> >>> >>> On Monday, 8 May 2017 16:42:17 UTC+2, Ray Cromwell wrote: The adapter class adds overhead though and you need to convert into and out of it every time you pass it to JS. At that point you may as well use Java.util.List and write an adapter around JS array. On Mon, May 8, 2017 at 7:10 AM Jens wrote: > IMHO if you want a JavaScript array, set, map behave the same as a > Java collection, so you can use it with other libraries, you should write > an adapter class that implements the Java API and operates internally on > the JavaScript data type. > > Basically do not rely on invisible magic. That could easily be > implemented as a 3rd party project. > > -- J. > > -- > 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-contributor > s+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.co
Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.
HI, what are the replacements for elemental2.Global.window and similar in this new release? -- 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/51b6fa49-b782-4f7e-9311-e812c8139433%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.
On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote: > > HI, what are the replacements for elemental2.Global.window and similar in > this new release? > elemental2.DomGlobal.window (in elemental2-dom dependency) -- 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/267a51d4-072e-4492-989a-8860c1daafae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: JsInterop & collections
> I believe it was in plans with @JsConvert – see slides 67 – 69. > https://docs.google.com/file/d/0ByS1wxINeBWjeGYxbkJpamxFZ28/edit > I think this is more meant to be used with non-native JsTypes. When you have a JsType implemented in Java and some JavaScript gives you JS through the Java object's public JS api. That way you can simply generate a delegate method that wraps the Js Array and provides the Java collection API on top of it. However if you use native JsTypes together with JSON.parse() for convert JSON back to JavaScriptObjects you are only dealing with a naming convention and nothing more. Basically JSON.parse() sees your server generated JSON and will construct JS objects natively. Given that JSON.parse() only understands JS Objects, JsArrays and primitives the native JsType you will cast the result of JSON.parse() into, can also only have these types in order to access the underlying data. So if your server REST implementation serializes a Map as two JSON arrays (one for keys, one for values) then your native JsType also needs two JsArray fields in order to access them. The only thing you can do is define a @JsOverlay method that returns a Map implementation that wraps the two JsArrays and then use that @JsOverlay method in your code to get a Map view. Given that you can only modify native JSON.parse() behavior to a limited extend I don't see any other way how a native JsType could transparently add an adapter around JsArrays in a configurable way (different REST server implementations might serialize maps in different ways) other then using @JsOverlay methods. -- J. -- 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/8e4d0bdb-8dde-45dd-a166-e132efbb1750%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: JsInterop & collections
On Tuesday, May 9, 2017 at 12:08:12 PM UTC+2, Marcin Okraszewski wrote: > > In short I would like JS arrays to be visible in GWT as a List and objects > parsed from JSON also as a Map. > > Maybe I'll try one more time to explain what we have. We share model > between server and GWT in form of java interfaces. Those interfaces are > declared as return types of Jersey services, which serve instances of those > interfaces. GWT uses exactly the same interfaces and handles them with > AutoBeans. It works quite well, but there are two issues. First issue is > that occasionally we need to pass some part of the data to JS. More often > than not, it is a list or contains a list. As a result, we need to > repackage it, as GWT objects are not understood by JS. Now we plan to > leverage more JS, so we will have to deal with this problem more often. > Second issue is that AutoBeans turned out to be inefficient in larger > scale, as the generated code is roughly 50% of our written code. > > So, we came up with following idea: let’s keep shared interfaces, just > annotate them with @JsType(native=true). Then use regular browser’s JSON > parser and cast parsed object into model interface with @JsType. It works > like charm for simple objects, but not for collections - List is being > parsed as an JS array; Map is nothing else but just regular object. > Dropping support for java collections, would be very expensive, and would > require heavy refactoring, as the app is big (over 0.5 million Java lines > in GWT + affected server parts). I thought there could be a way to tell > JsInterop that specific field is backed by a plain array (or list) and an > object (for map). > How about using the 'reviver' argument of JSON.parse() to copy/wrap arrays into lists? (would be harder to detect those objets that you want into maps though; the "reviver" could probably be generated from your interfaces to match on the key name though – this is something I've been thinking about for a few days actually, I really need to put my thoughts together in a gist or a message to this list) https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse -- 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/642a383f-ce8a-4224-b778-9bcecf6dbe44%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.
On Tuesday, May 9, 2017 at 1:03:41 PM UTC+2, Thomas Broyer wrote: > > > > On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote: >> >> HI, what are the replacements for elemental2.Global.window and similar >> in this new release? >> > > elemental2.DomGlobal.window (in elemental2-dom dependency) > Thanks! Another inconsistency with the previous release of elemental2 which broke my code is the use of elemental2.core.Function for the onreadystatechange field in the elemental2.dom.XMLHttpRequest type which prevents providing the function as a lambda. Other function fields in the mentioned type (e.g. onprogress or onloadstart) seem to keep the functional interface semantics. Is this intended or is it an oversight? -- 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/38ba78bf-4169-420d-9c41-034db9bafd61%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.
On Tuesday, May 9, 2017 at 2:02:40 PM UTC+2, Daniel Harezlak wrote: > > > > On Tuesday, May 9, 2017 at 1:03:41 PM UTC+2, Thomas Broyer wrote: >> >> >> >> On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote: >>> >>> HI, what are the replacements for elemental2.Global.window and similar >>> in this new release? >>> >> >> elemental2.DomGlobal.window (in elemental2-dom dependency) >> > Thanks! > > Another inconsistency with the previous release of elemental2 which broke > my code is the use of elemental2.core.Function for the onreadystatechange > field in the elemental2.dom.XMLHttpRequest type which prevents providing > the function as a lambda. Other function fields in the mentioned type (e.g. > onprogress or onloadstart) seem to keep the functional interface > semantics. Is this intended or is it an oversight? > I believe it's due to how they're declared in the Closure externs: onreadystatechange and onerror: https://github.com/google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172df3f/externs/browser/w3c_xml.js#L393-L403 vs all the other callbacks: https://github.com/google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2ccaac747722b/externs/browser/html5.js#L2828-L2862 -- 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/e1331a22-74f7-4648-b76b-0a2fb43a2dfc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: JsInterop & collections
There is indeed something in it. Actually you could have some type of naming convention, like in TJSON (https://tonyarcieri.com/introducing-tjson-a-stricter-typed-form-of-json) or TypedJson (https://www.npmjs.com/package/typed-json) to figure out proper types. But then I would need to create eg. ArrayList with the Manuel's trick (the asList() from Polymer). I'll test it. On Tuesday, 9 May 2017 13:30:40 UTC+2, Thomas Broyer wrote: > > > On Tuesday, May 9, 2017 at 12:08:12 PM UTC+2, Marcin Okraszewski wrote: >> >> In short I would like JS arrays to be visible in GWT as a List and >> objects parsed from JSON also as a Map. >> >> Maybe I'll try one more time to explain what we have. We share model >> between server and GWT in form of java interfaces. Those interfaces are >> declared as return types of Jersey services, which serve instances of those >> interfaces. GWT uses exactly the same interfaces and handles them with >> AutoBeans. It works quite well, but there are two issues. First issue is >> that occasionally we need to pass some part of the data to JS. More often >> than not, it is a list or contains a list. As a result, we need to >> repackage it, as GWT objects are not understood by JS. Now we plan to >> leverage more JS, so we will have to deal with this problem more often. >> Second issue is that AutoBeans turned out to be inefficient in larger >> scale, as the generated code is roughly 50% of our written code. >> >> So, we came up with following idea: let’s keep shared interfaces, just >> annotate them with @JsType(native=true). Then use regular browser’s JSON >> parser and cast parsed object into model interface with @JsType. It works >> like charm for simple objects, but not for collections - List is being >> parsed as an JS array; Map is nothing else but just regular object. >> Dropping support for java collections, would be very expensive, and would >> require heavy refactoring, as the app is big (over 0.5 million Java lines >> in GWT + affected server parts). I thought there could be a way to tell >> JsInterop that specific field is backed by a plain array (or list) and an >> object (for map). >> > > How about using the 'reviver' argument of JSON.parse() to copy/wrap arrays > into lists? (would be harder to detect those objets that you want into maps > though; the "reviver" could probably be generated from your interfaces to > match on the key name though – this is something I've been thinking about > for a few days actually, I really need to put my thoughts together in a > gist or a message to this list) > > https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse > > -- 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/e23d68e5-3f89-41ea-a2ae-b240f2ea1b33%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: JsInterop & collections
On Tuesday, May 9, 2017 at 4:34:48 PM UTC+2, Marcin Okraszewski wrote: > > There is indeed something in it. Actually you could have some type of > naming convention, like in TJSON ( > https://tonyarcieri.com/introducing-tjson-a-stricter-typed-form-of-json) > or TypedJson (https://www.npmjs.com/package/typed-json) to figure out > proper types. But then I would need to create eg. ArrayList with the > Manuel's trick (the asList() from Polymer). I'll test it. > java.util.Arrays.asList() should be enough actually: https://github.com/gwtproject/gwt/blob/2.8.1/user/super/com/google/gwt/emul/java/util/Arrays.java#L136 (note that the ArrayList there is not java.util.ArrayList, it's an internal java.util.Arrays.ArrayList class that directly wraps the array with no copy). -- 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/95e1bd43-b4a6-4b2d-bd89-6cc6fb206631%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.
> I believe it's due to how they're declared in the Closure externs:
onreadystatechange and onerror:
https://github.com/google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172df3f/externs/browser/w3c_xml.js#L393-L403
vs all the other callbacks:
https://github.com/google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2ccaac747722b/externs/browser/html5.js#L2828-L2862
Yes, the externs use the Function object as type instead of using a
function type like {function():any}.
We'll fix that for the next version.
On Tue, May 9, 2017 at 6:02 AM Thomas Broyer wrote:
>
>
> On Tuesday, May 9, 2017 at 2:02:40 PM UTC+2, Daniel Harezlak wrote:
>>
>>
>>
>> On Tuesday, May 9, 2017 at 1:03:41 PM UTC+2, Thomas Broyer wrote:
>>>
>>>
>>>
>>> On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote:
HI, what are the replacements for elemental2.Global.window and similar
in this new release?
>>>
>>> elemental2.DomGlobal.window (in elemental2-dom dependency)
>>>
>> Thanks!
>>
>> Another inconsistency with the previous release of elemental2 which broke
>> my code is the use of elemental2.core.Function for the onreadystatechange
>> field in the elemental2.dom.XMLHttpRequest type which prevents providing
>> the function as a lambda. Other function fields in the mentioned type (e.g.
>> onprogress or onloadstart) seem to keep the functional interface
>> semantics. Is this intended or is it an oversight?
>>
>
> I believe it's due to how they're declared in the Closure externs:
> onreadystatechange and onerror:
> https://github.com/google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172df3f/externs/browser/w3c_xml.js#L393-L403
> vs all the other callbacks:
> https://github.com/google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2ccaac747722b/externs/browser/html5.js#L2828-L2862
>
>
> --
> 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/e1331a22-74f7-4648-b76b-0a2fb43a2dfc%40googlegroups.com
>
> .
> 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/CABb_3%3D6wNB25OWdgjbJrYk8vpozWqaNz7XtBa3K6rgn-3fq2ZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.
I forgot to mention: as a workaround, you can create your own JsFunction
callback and cast it to Function:
@JsFunction
interface MyJsFunction {
void onInvoke();
default Function asFunction() {
return (Function) this;
}
}
On Tue, May 9, 2017 at 9:37 AM Julien Dramaix
wrote:
> > I believe it's due to how they're declared in the Closure externs:
> onreadystatechange and onerror:
> https://github.com/google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172df3f/externs/browser/w3c_xml.js#L393-L403
> vs all the other callbacks:
> https://github.com/google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2ccaac747722b/externs/browser/html5.js#L2828-L2862
>
> Yes, the externs use the Function object as type instead of using a
> function type like {function():any}.
> We'll fix that for the next version.
>
> On Tue, May 9, 2017 at 6:02 AM Thomas Broyer wrote:
>
>>
>>
>> On Tuesday, May 9, 2017 at 2:02:40 PM UTC+2, Daniel Harezlak wrote:
>>>
>>>
>>>
>>> On Tuesday, May 9, 2017 at 1:03:41 PM UTC+2, Thomas Broyer wrote:
On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote:
>
> HI, what are the replacements for elemental2.Global.window and
> similar in this new release?
>
elemental2.DomGlobal.window (in elemental2-dom dependency)
>>> Thanks!
>>>
>>> Another inconsistency with the previous release of elemental2 which
>>> broke my code is the use of elemental2.core.Function for the
>>> onreadystatechange field in the elemental2.dom.XMLHttpRequest type
>>> which prevents providing the function as a lambda. Other function fields in
>>> the mentioned type (e.g. onprogress or onloadstart) seem to keep the
>>> functional interface semantics. Is this intended or is it an oversight?
>>>
>>
>> I believe it's due to how they're declared in the Closure externs:
>> onreadystatechange and onerror:
>> https://github.com/google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172df3f/externs/browser/w3c_xml.js#L393-L403
>> vs all the other callbacks:
>> https://github.com/google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2ccaac747722b/externs/browser/html5.js#L2828-L2862
>>
>>
>> --
>> 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/e1331a22-74f7-4648-b76b-0a2fb43a2dfc%40googlegroups.com
>>
>> .
>> 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/CABb_3%3D52vj1gbcf_MPq5UiThib3y0w4nDQHs0Bu8Sb6Ubg5Tyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.
BTW, if you are using elemental2, keep in mind that these are beta releases
to get feedback and APIs will keep changing until we finalize it. So be
prepared for breakages in releases until we do the final release cut.
On Tue, May 9, 2017 at 2:32 PM, Julien Dramaix
wrote:
> I forgot to mention: as a workaround, you can create your own JsFunction
> callback and cast it to Function:
> @JsFunction
> interface MyJsFunction {
> void onInvoke();
>
> default Function asFunction() {
> return (Function) this;
> }
> }
>
> On Tue, May 9, 2017 at 9:37 AM Julien Dramaix
> wrote:
>
>> > I believe it's due to how they're declared in the Closure externs:
>> onreadystatechange and onerror: https://github.com/
>> google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a13381
>> 72df3f/externs/browser/w3c_xml.js#L393-L403
>> vs all the other callbacks: https://github.com/
>> google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2cc
>> aac747722b/externs/browser/html5.js#L2828-L2862
>>
>> Yes, the externs use the Function object as type instead of using a
>> function type like {function():any}.
>> We'll fix that for the next version.
>>
>> On Tue, May 9, 2017 at 6:02 AM Thomas Broyer wrote:
>>
>>>
>>>
>>> On Tuesday, May 9, 2017 at 2:02:40 PM UTC+2, Daniel Harezlak wrote:
On Tuesday, May 9, 2017 at 1:03:41 PM UTC+2, Thomas Broyer wrote:
>
>
>
> On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote:
>>
>> HI, what are the replacements for elemental2.Global.window and
>> similar in this new release?
>>
>
> elemental2.DomGlobal.window (in elemental2-dom dependency)
>
Thanks!
Another inconsistency with the previous release of elemental2 which
broke my code is the use of elemental2.core.Function for the
onreadystatechange field in the elemental2.dom.XMLHttpRequest type
which prevents providing the function as a lambda. Other function fields in
the mentioned type (e.g. onprogress or onloadstart) seem to keep the
functional interface semantics. Is this intended or is it an oversight?
>>>
>>> I believe it's due to how they're declared in the Closure externs:
>>> onreadystatechange and onerror: https://github.com/
>>> google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a13381
>>> 72df3f/externs/browser/w3c_xml.js#L393-L403
>>> vs all the other callbacks: https://github.com/
>>> google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2cc
>>> aac747722b/externs/browser/html5.js#L2828-L2862
>>>
>>>
>>> --
>>> 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/e1331a22-74f7-
>>> 4648-b76b-0a2fb43a2dfc%40googlegroups.com
>>>
>>> .
>>> 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/CABb_3%3D52vj1gbcf_
> MPq5UiThib3y0w4nDQHs0Bu8Sb6Ubg5Tyw%40mail.gmail.com
>
> .
>
> 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%3DyUA06HZJf47%3DudrshQDxYyf53_QoHz_JZx3LfAUwsXWp%2B5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: JsInterop & collections
Yes, theoretically you should be able to use the second parameter on
Json.parse Json.stringify for conversion back and forth between java
collections and js primitives. In this model, your javascript code needs to
use Java collection APIs.
> java.util.Arrays.asList() should be enough
keep in mind that Arrays.asList won't let you go out of bounds.
> I believe it was in plans with @JsConvert
We are not working on @JsConvert right now. JsConvert is just convenience
and you can mimic it:
@JsType(isNative=true)
interface MyType {
@JsConvert(ListConverter.class)
List getMyArray()
void setMyArray(@JsConvert(ListConverter.class) List array)
}
is roughly equivalent to:
@JsType(isNative=true)
interface MyType {
@JsProperty(name="myArray")
Object[] getMyArrayInternal();
@JsOverlay
default List getMyArray() { return Arrays.asList(getMyArray()); }
@JsProperty(name="myArray")
void setMyArrayInternal(Object[] array);
@JsOverlay
default void setMyArray(List list) {
setMyArrayInternal(array.toArray());
}
}
On Tue, May 9, 2017 at 9:32 AM, Thomas Broyer wrote:
>
>
> On Tuesday, May 9, 2017 at 4:34:48 PM UTC+2, Marcin Okraszewski wrote:
>>
>> There is indeed something in it. Actually you could have some type of
>> naming convention, like in TJSON (https://tonyarcieri.com/intro
>> ducing-tjson-a-stricter-typed-form-of-json) or TypedJson (
>> https://www.npmjs.com/package/typed-json) to figure out proper types.
>> But then I would need to create eg. ArrayList with the Manuel's trick (the
>> asList() from Polymer). I'll test it.
>>
>
> java.util.Arrays.asList() should be enough actually: https://github.com/
> gwtproject/gwt/blob/2.8.1/user/super/com/google/gwt/
> emul/java/util/Arrays.java#L136 (note that the ArrayList there is not
> java.util.ArrayList, it's an internal java.util.Arrays.ArrayList class that
> directly wraps the array with no copy).
>
> --
> 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/95e1bd43-b4a6-
> 4b2d-bd89-6cc6fb206631%40googlegroups.com
>
> .
>
> 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%3DyUA0Wr0pWKUcqyN2YMkuoZZK7b3e-ipm7jqv2DdDeqk8sMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Minor thing with Elemental 2 DomGlobal.requestAnimationFrame
We will soon have a github repro but right now this is the right place to
report it.
It looks like closure definition is missing return definition:
https://github.com/google/closure-compiler/blob/master/externs/browser/w3c_anim_timing.js#L26
Updating that should resolve the issue. Could you file a bug in closure and
cc us as well?
On Tue, May 9, 2017 at 2:43 AM, Anders Forsell
wrote:
> Hi,
>
> I found a small annoyance with DomGlobal.requestAnimationFrame in that
> you have to supply a function which returns an Object.
>
> DomGlobal.requestAnimationFrame(event -> {
> myPresenter.loadContent();
> return null;
> });
>
> I'd like to be able to pass a void method, where should I report this?
>
> Anders
>
>
> --
> 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/d6469b0d-43a1-
> 4ea3-9292-7a07d7b73dd8%40googlegroups.com
>
> .
> 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%3DyUA0hEVnL6Qs%3D74q2zEoPCpn4WaicsaY788ZtfK2neu%2BbwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: JsInterop & collections
I think it would be better to use a JsArrayListAdapter in order to prevent
making copies all over the place, and also making mutations write-through
on both sides e.g.
public class JsArrayListAdapter extends AbstractList {
public JsArrayListAdapter(ArrayLike blah) {
this.array = blah;
}
// implement List methods to delegate to Array methods
}
To keep referential integrity, you need to use an expando or ES6 Symbol
property to hide a backreference.
That is, JsArrayListAdapter.wrap(nativeJsArray) ==
JsArrayListAdapter.wrap(nativeJsArray2) IFF nativeJsArray == nativeJsArray2.
This technique is less error prone IMHO if you are going to have mutable
objects. If you're using immutables, then making copies is superior.
On Tue, May 9, 2017 at 3:24 PM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> Yes, theoretically you should be able to use the second parameter on
> Json.parse Json.stringify for conversion back and forth between java
> collections and js primitives. In this model, your javascript code needs to
> use Java collection APIs.
>
> > java.util.Arrays.asList() should be enough
>
> keep in mind that Arrays.asList won't let you go out of bounds.
>
>
>
> > I believe it was in plans with @JsConvert
>
>
> We are not working on @JsConvert right now. JsConvert is just convenience
> and you can mimic it:
>
>
> @JsType(isNative=true)
> interface MyType {
> @JsConvert(ListConverter.class)
> List getMyArray()
> void setMyArray(@JsConvert(ListConverter.class) List array)
> }
>
> is roughly equivalent to:
>
> @JsType(isNative=true)
> interface MyType {
> @JsProperty(name="myArray")
> Object[] getMyArrayInternal();
>
> @JsOverlay
> default List getMyArray() { return Arrays.asList(getMyArray()); }
>
> @JsProperty(name="myArray")
> void setMyArrayInternal(Object[] array);
>
> @JsOverlay
> default void setMyArray(List list) {
>setMyArrayInternal(array.toArray());
> }
> }
>
>
> On Tue, May 9, 2017 at 9:32 AM, Thomas Broyer wrote:
>
>>
>>
>> On Tuesday, May 9, 2017 at 4:34:48 PM UTC+2, Marcin Okraszewski wrote:
>>>
>>> There is indeed something in it. Actually you could have some type of
>>> naming convention, like in TJSON (
>>> https://tonyarcieri.com/introducing-tjson-a-stricter-typed-form-of-json)
>>> or TypedJson (https://www.npmjs.com/package/typed-json) to figure out
>>> proper types. But then I would need to create eg. ArrayList with the
>>> Manuel's trick (the asList() from Polymer). I'll test it.
>>>
>>
>> java.util.Arrays.asList() should be enough actually:
>> https://github.com/gwtproject/gwt/blob/2.8.1/user/super/com/google/gwt/emul/java/util/Arrays.java#L136
>> (note that the ArrayList there is not java.util.ArrayList, it's an internal
>> java.util.Arrays.ArrayList class that directly wraps the array with no
>> copy).
>>
>> --
>> 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/95e1bd43-b4a6-4b2d-bd89-6cc6fb206631%40googlegroups.com
>>
>> .
>>
>> 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%3DyUA0Wr0pWKUcqyN2YMkuoZZK7b3e-ipm7jqv2DdDeqk8sMA%40mail.gmail.com
>
> .
> 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/CAPVRV7djBFDAMLmxa8FqL_PXLBDLoi1ehtiWjPJ0KNc3owF4Tw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.
Question about OscilatorNode
(https://github.com/google/closure-compiler/blob/c77ca197a1f6674e4c267a29a3643a86b61cf51d/externs/browser/w3c_audio.js)
This start method is translated as a "StartCallbackFunction start", should
it not be translated as a method directly? This callback field cannot be
called so it doesn't work.
/** @param {number=} when */
OscillatorNode.prototype.start = function(when) {};
Example usage here
(https://github.com/ibaca/rxbreakout-gwt/blob/master/src/main/java/breakout/client/Breakout.java#L179).
On Wednesday, May 10, 2017 at 12:06:12 AM UTC+2, Goktug Gokdogan wrote:
>
> BTW, if you are using elemental2, keep in mind that these are beta
> releases to get feedback and APIs will keep changing until we finalize it.
> So be prepared for breakages in releases until we do the final release cut.
>
> On Tue, May 9, 2017 at 2:32 PM, Julien Dramaix > wrote:
>
>> I forgot to mention: as a workaround, you can create your own JsFunction
>> callback and cast it to Function:
>> @JsFunction
>> interface MyJsFunction {
>> void onInvoke();
>>
>> default Function asFunction() {
>> return (Function) this;
>> }
>> }
>>
>> On Tue, May 9, 2017 at 9:37 AM Julien Dramaix > > wrote:
>>
>>> > I believe it's due to how they're declared in the Closure externs:
>>> onreadystatechange and onerror:
>>> https://github.com/google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172df3f/externs/browser/w3c_xml.js#L393-L403
>>> vs all the other callbacks:
>>> https://github.com/google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2ccaac747722b/externs/browser/html5.js#L2828-L2862
>>>
>>> Yes, the externs use the Function object as type instead of using a
>>> function type like {function():any}.
>>> We'll fix that for the next version.
>>>
>>> On Tue, May 9, 2017 at 6:02 AM Thomas Broyer >> > wrote:
>>>
On Tuesday, May 9, 2017 at 2:02:40 PM UTC+2, Daniel Harezlak wrote:
>
>
>
> On Tuesday, May 9, 2017 at 1:03:41 PM UTC+2, Thomas Broyer wrote:
>>
>>
>>
>> On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote:
>>>
>>> HI, what are the replacements for elemental2.Global.window and
>>> similar in this new release?
>>>
>>
>> elemental2.DomGlobal.window (in elemental2-dom dependency)
>>
> Thanks!
>
> Another inconsistency with the previous release of elemental2 which
> broke my code is the use of elemental2.core.Function for the
> onreadystatechange field in the elemental2.dom.XMLHttpRequest type
> which prevents providing the function as a lambda. Other function fields
> in
> the mentioned type (e.g. onprogress or onloadstart) seem to keep the
> functional interface semantics. Is this intended or is it an oversight?
>
I believe it's due to how they're declared in the Closure externs:
onreadystatechange and onerror:
https://github.com/google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172df3f/externs/browser/w3c_xml.js#L393-L403
vs all the other callbacks:
https://github.com/google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2ccaac747722b/externs/browser/html5.js#L2828-L2862
--
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/e1331a22-74f7-4648-b76b-0a2fb43a2dfc%40googlegroups.com
.
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/CABb_3%3D52vj1gbcf_MPq5UiThib3y0w4nDQHs0Bu8Sb6Ubg5Tyw%40mail.gmail.com
>>
>>
>> .
>>
>> 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
