A new experimental version of Elemental2 using the new JsInterop specification has been pushed on Sonatype today.
You can try it by downloading the jar file or adding this following maven dependency:
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>elemental2-experimental</artifactId>
<version>16-06-30</version>
</dependency>
Then, inherits the elemental2 module:
<inherits name="elemental2" />
This experimental version works only with the last 2.8-snapshot release of GWT.
The goal of this release is to get feedback so don’t hesitate to report any bugs, issues, concerns you have on this mailing list.
Important note: This is an experimental release and without doubt the future updates until the final release are going to break code!
- Julien
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABXeq2Q%3DuH8beWj4tiG28tycASsJxK8mnxxNPZnEykUeTcMWXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
package elemental.sample.simple;
import static elemental2.Global.alert;
import static elemental2.Global.document;
import com.google.gwt.core.client.EntryPoint;
import elemental2.Event;
import elemental2.EventListener;
import elemental2.HTMLButtonElement;
public class SimpleApp implements EntryPoint{
public void onModuleLoad() {
final HTMLButtonElement button = (HTMLButtonElement) document.createElement("button");
button.textContent = "Click me";
button.addEventListener(
"click",
new EventListener() {
@Override
public void handleEvent(Event evt) {
button.parentNode.removeChild(button);
alert("Button has been removed.");
}
});
document.body.appendChild(button);
}
}
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%40googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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-co...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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-co...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5M5DQS--awYZ1bS8nHBu9po8Ne8JPY_ianrUjNZrSqyg%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 view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/08b1f7b2-3682-4c83-977d-79c729cc2796%40googlegroups.com.To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5M5DQS--awYZ1bS8nHBu9po8Ne8JPY_ianrUjNZrSqyg%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+unsubscribe@googlegroups.com.
Yep, not sure why... but I just try again and the parameter is used correctly by the codeserver, so it works as you said. When you said 'you are implementing a native JsType' you are talking about the JsFunction callbacks, isn't it?
The issue said 'do not honor' so looks like the opposite direction (I mean, 'do not honor' is what is happening before issue is fixed or what should happen after the issue is fixed).
To confirm, will this issue make this native JsFunction callbacks works without the export flag?
>> email to google-web-toolkit-co...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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-co...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5M5DQS--awYZ1bS8nHBu9po8Ne8JPY_ianrUjNZrSqyg%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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/08b1f7b2-3682-4c83-977d-79c729cc2796%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e885d86d-cb93-4f4e-a086-f0e2ea803d27%40googlegroups.com.To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5M5DQS--awYZ1bS8nHBu9po8Ne8JPY_ianrUjNZrSqyg%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/08b1f7b2-3682-4c83-977d-79c729cc2796%40googlegroups.com.
--
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+unsubscribe@googlegroups.com.
Thanks, now makes sense. I get confused with the JsFunction JsType(native) because elemental2 has some callbacks as JsFunction and others as JsType(native), now an actual elemental2 question; what criteria is used to apply JsFunction (ex. elemental2.Node.AddEventListenerCallback) instead of JsType (ex. elemental2.JsType)?
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/73b36bdb-c496-4768-a221-21fe8b5a437c%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0ZfCbS%2Bnwtre0QuAnhDdLYz%2B3LuzXqD3WqoWqK%3DFe%2BEg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsU1UZgkh3cjG1HPkpRBJfaiEh631fq9WdS_RQg8Z_Leg%40mail.gmail.com.
It seems that the deployed dependency is inconsistent.The pom.xml says "elemental-experimental" with version "2016-06-30".But the dependency is available as "elemental2-experimental" with version "16-06-30".
So gradle is not able to resolve the dependency.Warning:project ':frontend': Web Facets/Artifacts will not be configured properlyDetails: org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':frontend:runtime'.Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.google.gwt:elemental2-experimental:16-06-30.Required by:itdidea:frontend:unspecifiedCaused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.google.gwt:elemental2-experimental:16-06-30.Caused by: org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.MetaDataParseException: inconsistent module metadata found. Descriptor: com.google.gwt:elemental-experimental:2016-06-29 Errors: bad module name: expected='elemental2-experimental' found='elemental-experimental'bad version: expected='16-06-30' found='2016-06-29'
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsU1UZgkh3cjG1HPkpRBJfaiEh631fq9WdS_RQg8Z_Leg%40mail.gmail.com.
Would it be possible to break the project into a few packages? It would make it easier to find things.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/127fd7d4-56ab-407e-9981-1da8d2d91a91%40googlegroups.com.
I'm wondering if it would be possible to have type-safe convenience methods for creating elements, so as the user does not have to provide the string tag name, nor cast the object, maybe something like :HTMLButtonElement button = HTMLButtonElement.createElement();instead ofHTMLButtonElement button = (HTMLButtonElement) document.createElement("button");
El sáb., 2 jul. 2016 a las 4:38, 'Goktug Gokdogan' via GWT Contributors (<google-web-toolkit-contri...@googlegroups.com>) escribió:
Closure extern definition uses a union type here:So it accepts either EventListener interface or a function.When we see a union type, we generate overloads for each type so Elemental should provide overloads that includes both. And it seems like it does. If not please let us know.
On Fri, Jul 1, 2016 at 3:39 AM, Jens <jens.ne...@gmail.com> wrote:
Thanks, now makes sense. I get confused with the JsFunction JsType(native) because elemental2 has some callbacks as JsFunction and others as JsType(native), now an actual elemental2 question; what criteria is used to apply JsFunction (ex. elemental2.Node.AddEventListenerCallback) instead of JsType (ex. elemental2.JsType)?I think its the result of definition of EventTarget.addEventListener():
listener - The object that receives a notification (an object that implements the Event interface) when an event of the specified type occurs. This must be an object implementing the EventListener interface, or simply a JavaScript function.The EventListener interface is a defined API and thus a @JsType(isNative = true) interface has been generated. But to conform to "or simply a JavaScript function" there is also an AddEventListenerCallback that is a @JsFunction. Not sure if this distinction has any real value, in a hand coded elemental2 I would have only created a @JsFunction interface EventListener-- 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/73b36bdb-c496-4768-a221-21fe8b5a437c%40googlegroups.com.
--
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+unsubscribe@googlegroups.com.
context_ = (CanvasRenderingContext2D) (Object) canvas.getContext("2d")
Elemental2 currently purely driven by the JavaScript extern files. So it is not trivial. Maybe a later version could include some kind of type extension.For now perhaps we can improve the generated code to use generics so you don't need to cast but we cannot modify the API.
On Sat, Jul 2, 2016 at 2:07 PM, Manuel Carrasco Moñino <man...@apache.org> wrote:
I'm wondering if it would be possible to have type-safe convenience methods for creating elements, so as the user does not have to provide the string tag name, nor cast the object, maybe something like :HTMLButtonElement button = HTMLButtonElement.createElement();instead ofHTMLButtonElement button = (HTMLButtonElement) document.createElement("button");
El sáb., 2 jul. 2016 a las 4:38, 'Goktug Gokdogan' via GWT Contributors (<google-web-toolkit-contri...@googlegroups.com>) escribió:
Closure extern definition uses a union type here:So it accepts either EventListener interface or a function.When we see a union type, we generate overloads for each type so Elemental should provide overloads that includes both. And it seems like it does. If not please let us know.
On Fri, Jul 1, 2016 at 3:39 AM, Jens <jens.ne...@gmail.com> wrote:
Thanks, now makes sense. I get confused with the JsFunction JsType(native) because elemental2 has some callbacks as JsFunction and others as JsType(native), now an actual elemental2 question; what criteria is used to apply JsFunction (ex. elemental2.Node.AddEventListenerCallback) instead of JsType (ex. elemental2.JsType)?I think its the result of definition of EventTarget.addEventListener():
listener - The object that receives a notification (an object that implements the Event interface) when an event of the specified type occurs. This must be an object implementing the EventListener interface, or simply a JavaScript function.The EventListener interface is a defined API and thus a @JsType(isNative = true) interface has been generated. But to conform to "or simply a JavaScript function" there is also an AddEventListenerCallback that is a @JsFunction. Not sure if this distinction has any real value, in a hand coded elemental2 I would have only created a @JsFunction interface EventListener-- 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/73b36bdb-c496-4768-a221-21fe8b5a437c%40googlegroups.com.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0ZfCbS%2Bnwtre0QuAnhDdLYz%2B3LuzXqD3WqoWqK%3DFe%2BEg%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+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/73b36bdb-c496-4768-a221-21fe8b5a437c%40googlegroups.com.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0ZfCbS%2Bnwtre0QuAnhDdLYz%2B3LuzXqD3WqoWqK%3DFe%2BEg%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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsU1UZgkh3cjG1HPkpRBJfaiEh631fq9WdS_RQg8Z_Leg%40mail.gmail.com.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/023e92c6-8f9f-41b4-8203-369b82499d7f%40googlegroups.com.
I do think we should have another library that builds on Elemental2. While browser compatibility is a lot better, it still isn't perfect and we need somewhere to collect workarounds for specific issues and add helper functions to make working with the library easier.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/71f5352a-41dc-4f91-a22b-9a9bb21b8bbb%40googlegroups.com.
> - often method signature defines Object as return type while I am pretty sure something more concrete would be more appropriate.if a method "getFoo" can return different types "string or Foo", we create different methods :public Object getFoo();public String getFooAsString();public Foo getFooAsFoo();In the future there will be javadoc above the methods mentioning these links between a set of methods.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/fa7580d3-f355-44e1-a923-c588b3c6da45%40googlegroups.com.
searchButton.addEventListener("click",e -> doSearch());
searchButton.addEventListener("click", e-> {doSearch();return true;});
It only works with the generateJsInteropExports flag set though.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/16498b97-7d3d-44c7-b42b-e40be9de1e26%40googlegroups.com.
Can you share a small repro for this? (EventListener requiring generateJsInteropExports)
On Thu, Jul 28, 2016 at 12:27 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've done some more testing and cleared my cache and can still only get EventListener to work with the generateJsInteropExports flag set.I've had another problem with EventListener on a select element but I'm using an external framework for my project (Materialize) and think that it's their framework that doesn't like the EventListener object. If I use a standard select element then it's working. I can get around this by adding the listener through a JQuery wrapper so no problem.I've also found that Window.location returns an Object - will this be sorted in a future release?Other than that Elemental is working well so far! Nice work!Steve
On Friday, 22 July 2016 11:31:24 UTC+1, Jens wrote:It only works with the generateJsInteropExports flag set though.Sounds like a bug to me.-- 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+unsubscribe@googlegroups.com.
I've created a quick test project and put it at https://github.com/steveandrews01/JsInteropTestThe click listener only works if compiled with the flag set. If I run it without the flag and inspect the DOM in Chrome then the event listener is not attached to the button.(Changing the flag needs a SDM cache clear!)Steve
On Monday, 1 August 2016 20:48:13 UTC+1, Goktug Gokdogan wrote:
Can you share a small repro for this? (EventListener requiring generateJsInteropExports)
On Thu, Jul 28, 2016 at 12:27 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've done some more testing and cleared my cache and can still only get EventListener to work with the generateJsInteropExports flag set.I've had another problem with EventListener on a select element but I'm using an external framework for my project (Materialize) and think that it's their framework that doesn't like the EventListener object. If I use a standard select element then it's working. I can get around this by adding the listener through a JQuery wrapper so no problem.I've also found that Window.location returns an Object - will this be sorted in a future release?Other than that Elemental is working well so far! Nice work!Steve
On Friday, 22 July 2016 11:31:24 UTC+1, Jens wrote:It only works with the generateJsInteropExports flag set though.Sounds like a bug to me.-- 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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/16498b97-7d3d-44c7-b42b-e40be9de1e26%40googlegroups.com.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/fca60fc6-7cfd-44ea-9728-295c77293d74%40googlegroups.com.
Looking at the elemental code that uses a lambda which will not be EventHandler but a JsFunction. Could you try with an anonymous EventHandler instead?
On Tue, Aug 2, 2016 at 1:51 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've created a quick test project and put it at https://github.com/steveandrews01/JsInteropTestThe click listener only works if compiled with the flag set. If I run it without the flag and inspect the DOM in Chrome then the event listener is not attached to the button.(Changing the flag needs a SDM cache clear!)Steve
On Monday, 1 August 2016 20:48:13 UTC+1, Goktug Gokdogan wrote:
Can you share a small repro for this? (EventListener requiring generateJsInteropExports)
On Thu, Jul 28, 2016 at 12:27 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've done some more testing and cleared my cache and can still only get EventListener to work with the generateJsInteropExports flag set.I've had another problem with EventListener on a select element but I'm using an external framework for my project (Materialize) and think that it's their framework that doesn't like the EventListener object. If I use a standard select element then it's working. I can get around this by adding the listener through a JQuery wrapper so no problem.I've also found that Window.location returns an Object - will this be sorted in a future release?Other than that Elemental is working well so far! Nice work!Steve
On Friday, 22 July 2016 11:31:24 UTC+1, Jens wrote:It only works with the generateJsInteropExports flag set though.Sounds like a bug to me.-- 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/16498b97-7d3d-44c7-b42b-e40be9de1e26%40googlegroups.com.
--
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+unsubscribe@googlegroups.com.
- Is there a possibility that the API's don't overuse double in the future ? For example the XMLHttpRequest.status property is supposed to be an integer not a double.
- The API's do not use set/get/is as was the case in the old Elemental. So how can I now detect that a property is readOnly ?
Some comments:
- Is there a possibility that the API's don't overuse double in the future ? For example the XMLHttpRequest.status property is supposed to be an integer not a double.
- The API's do not use set/get/is as was the case in the old Elemental. So how can I now detect that a property is readOnly ?
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a39c2d63-82e7-4131-8804-7cecd70af0de%40googlegroups.com.
- The API's do not use set/get/is as was the case in the old Elemental. So how can I now detect that a property is readOnly ?
On Mon, Aug 8, 2016 at 6:40 AM, stuckagain <david...@gmail.com> wrote:Some comments:
- Is there a possibility that the API's don't overuse double in the future ? For example the XMLHttpRequest.status property is supposed to be an integer not a double.Yes, we will look into.- The API's do not use set/get/is as was the case in the old Elemental. So how can I now detect that a property is readOnly ?
We can probably make it final but if we know it is readonly but I think we are not sure when the field is readonly. Julien?
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a39c2d63-82e7-4131-8804-7cecd70af0de%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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA22pvB4kqUCF9figh9FHTdEHk_nB39wqx7_EFng3VKicQ%40mail.gmail.com.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/cd662014-000e-4823-8eab-0acb469c574c%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6y-xP%3DUU-LzPBXj68KPycBT6hdep%3DFehbh8QbPvb_vJQ%40mail.gmail.com.
This generator will take GWT to the next level. Integrating GWT with existing js libraries was always time-consuming and error-prone (using either JNSI or jinterop).
What is the status of it (what is holding back the project from being open-sourced)? Can we help in any way?
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/7100c19d-2372-4461-8efc-3ccf2c513116%40googlegroups.com.
[javac] /Users/john/.../src/com/App.java:208: error: reference to addEventListener is ambiguous
[javac] doc.getElementById("list").addEventListener("click", event -> listPressed(event));
[javac] ^
[javac] both method addEventListener(String,AddEventListenerListenerCallback) in Node and method addEventListener(String,EventListener) in Node match
.addEventListener("click", (EventListener)event -> listPressed(event));
@JsType(isNative = true, namespace = JsPackage.GLOBAL)
public class HTMLElementEx extends HTMLElement {
public String outerHTML;
public HTMLCollection<HTMLElement> children;
}
A new experimental version of Elemental2 using the new JsInterop specification has been pushed on Sonatype today.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d4cb6c43-cd40-494d-88eb-2aa786a18b6a%40googlegroups.com.
What data sources does it consume? Does it take Typescript or Web IDL as input or something else?
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/eec8a65f-991d-4b88-9dcf-ad6956beb060%40googlegroups.com.
It's a little unfortunate that Elemental is being developed privately since it's the one part of GWT that's self-contained enough that I am able and willing to contribute to it. But is it possible to get an early, unofficial, unsupported code drop of the current Elemental code generator?
I'm a big user of Elemental 1, and I'm thinking about custom generating my own framework instead of using Elemental 2 so that I can have an API that works better with my own workflow. Being able to see the existing code generator would help me in knowing how much work would be involved and would allow me to avoid duplicating effort.
If that's not possible, would it be possible to at least get some details about the implementation? Is it written in Python like Elemental 1 was or is it written in Java? What data sources does it consume? Does it take Typescript or Web IDL as input or something else?
Thanks-Ming
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/507ab806-d365-4889-81ce-ece6c0e7885a%40googlegroups.com.
Well, ok. Thanks.Just in terms of general feedback on Elemental2:1. I'm not sure whether the conversion of JavaScript properties to Java fields is the best choice. Sure, it "feels" more like the original JavaScript, but
a) it's inconsistent with Java semantics,
b) I'd be afraid that a Java compiler might apply some unexpected optimization there as a result,
c) it's harder to mock the behavior of the classes for unit tests
and d) alternate implementations of Elemental2 aren't possible (for example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I did with Elemental 1).
2. Personally, I would prefer if Elemental 2 used interfaces over classes (for similar reason as above), though I understand that being able to use "new ...()" syntax on things is nice too.
3. The number of callback classes is out-of-control. Can they be consolidated somehow?
4. Also, is it possible to supplement the typing information for some of those callbacks from Typescript? Everyone knows that "onclick" handlers pass a MouseEvent. I'm not sure if Closure has a rich enough type system or is sufficiently well-developed to generate the best API there.
5. Can there be some magic that makes elemental2.Iterable<T> a real Java Iterable?
Otherwise, it seems nice. I like that there's a NodeList<T> now!
--
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+unsu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/cb2a997b-2d25-43c0-911a-ba13a448e14e%40googlegroups.com.
a) it's inconsistent with Java semantics,This could be a stylistic inconsistency not a semantic one. All arguments that I have seen in favor for having accessors instead of fields are inapplicable to Elemental fields since they all assume changes in the implementation of accessors which in our case always a pass through.However I am aware of the stylistic expectation from some java devs and we might end up providing setter/getter as overlays for people who would like to stick conventional style.
c) it's harder to mock the behavior of the classes for unit testsActually a field doesn't require mocking; but native accessor as you are proposing does require mocking.
4. Also, is it possible to supplement the typing information for some of those callbacks from Typescript? Everyone knows that "onclick" handlers pass a MouseEvent. I'm not sure if Closure has a rich enough type system or is sufficiently well-developed to generate the best API there.The language gap between TypeScript and Java is actually higher than Closure and Java. That makes it harder to precisely mimic type info that exists in d.ts via Java abstractions.Hopefully we could make this work better over time.
Thanks for the feedback.On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu <ji...@jinq.org> wrote:Well, ok. Thanks.Just in terms of general feedback on Elemental2:1. I'm not sure whether the conversion of JavaScript properties to Java fields is the best choice. Sure, it "feels" more like the original JavaScript, buta) it's inconsistent with Java semantics,This could be a stylistic inconsistency not a semantic one. All arguments that I have seen in favor for having accessors instead of fields are inapplicable to Elemental fields since they all assume changes in the implementation of accessors which in our case always a pass through.However I am aware of the stylistic expectation from some java devs and we might end up providing setter/getter as overlays for people who would like to stick conventional style.
a) it's inconsistent with Java semantics,This could be a stylistic inconsistency not a semantic one. All arguments that I have seen in favor for having accessors instead of fields are inapplicable to Elemental fields since they all assume changes in the implementation of accessors which in our case always a pass through.However I am aware of the stylistic expectation from some java devs and we might end up providing setter/getter as overlays for people who would like to stick conventional style.I guess I'm referring to how field access in Java are simply variable modifications whereas property accesses in JavaScript can trigger additional behaviors. In normal Java code, something likecanvas.width = 50is pretty inert. But in Elemental, that code automatically triggers a resizing and relayout of the element. Or perhaps a better example is innerHTML. Or even something likeel.scrollTop = -5;System.out.println(el.scrollTop); // prints out 0, which this is impossible in real JavaI'm not sure whether these would be described as semantic or stylistic differences. But they're unexpected.
c) it's harder to mock the behavior of the classes for unit testsActually a field doesn't require mocking; but native accessor as you are proposing does require mocking.Well, it sort of depends. Since JavaScript properties actually trigger additional behaviors, I might want to mock the properties to ensure these behaviors are being triggered correctly. I might want to mock innerHTML to ensure that the correct UI is being set-up and then use that trigger some additional mocking. (Or is this not mocking? I'm unclear on the correct test terminology for that.) I suppose that things can be worked around by just testing field values. And I'm not sure if people actually unit test user interfaces like that. It's just a trade-off, I suppose.
4. Also, is it possible to supplement the typing information for some of those callbacks from Typescript? Everyone knows that "onclick" handlers pass a MouseEvent. I'm not sure if Closure has a rich enough type system or is sufficiently well-developed to generate the best API there.The language gap between TypeScript and Java is actually higher than Closure and Java. That makes it harder to precisely mimic type info that exists in d.ts via Java abstractions.Hopefully we could make this work better over time.Sure. I was just thinking that it would be nice if the code generator could suck in additional data from other sources to supplement the info it can use to generate interfaces. The hand-built types in TypeScript is a good information source for event handlers. And Web IDL has good information on whether numbers are integers or floats. I'm just throwing it out there as possible future improvements.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/827ac42b-638f-49f4-b67b-0f3675808879%40googlegroups.com.