Google Web Toolkit: June 2015

Tuesday, June 30, 2015

Re: DateBox and TimeZone

Hi Eric,

Even i am having the same issue. i want timezone to be set to "america/los_angeles". how did you resolve it using airthmetic could you please explain.

I tried the following scenario.

created new Date() in java code so it will take server timezone i.e "america/los_angeles" n tried setting the startdate from front end which user entered. it works when "america/los_angeles" date is same as "asia/kolkata" but gives one day back when date is different like "asia/kolkata" 01/07/2015 10:00:00 am IST and "america/los_angeles" is "30/06/2015 9:30:00 pm PDT"

On Wednesday, June 29, 2011 at 7:35:56 AM UTC+5:30, Eric wrote:

So apparently no one know and/or no one cares ;)

Or this post just slipped through the cracks.

I ended up solving my problem with date arithmetic on the server side,
but I'm still curious if this is possible.

Thanks,
Eric

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

JsInterop question ...

Hey everyone, just a quick question regarding JsInterop: how is it proposed to manage javascript functions that can potentially take more than one type of parameter? For example, take the websocket interface:

@JsType(prototype = "WebSocket")
public interface WebSocket extends EventTarget {

  ... blah blah.

  void send(String data);
  // void send(Blob data); <-- JsInterop forbids this

}

I suppose that the following is possible

@JsType(prototype = "WebSocket")
public interface WebSocket extends EventTarget {

  void send(Object data);

}

but ... this doesn't seem ideal from a Java perspective :)

Regards,

Ben.

[ANN] gwt-places: the PlaceHistoryMapper generator ported as an annotation processor

Hi all,

I just pushed out gwt-places to GitHub: https://github.com/tbroyer/gwt-places

This is a port of the PlaceHistoryMapper generator as an annotation processor: I copied the code from GWT proper and replaced uses of com.google.gwt.core.ext. with javax.lang.model. and javax.annotation.processing; and code generation with JavaPoet.

The tests have been copied almost verbatim, only adapted to JUnit 4 and compile-testing (along with Truth assertions and a bit of Mockito), and Maven (using the maven-invoker-plugin to replace the GWTTestCase machinery and trigger the annotation processor).

This is more of an experiment for now, in preparation for GWT 3.0 which will nuke generators.

The annotation processor is triggered by the presence of the @WithTokenizers annotation. It means that if you use PlaceHistoryMapperWithFactory, you have to annotation your interface with @WithTokenizers even if all your tokenizers come from the factory; just use an empty list in this case: @WithTokenizers({}).

The annotation processor generates a class with the same name as the GWT generator (i.e. the name of your PlaceHistoryMapper subinterface with an "Impl" suffix), so you just have to replace GWT.create(MyPlaceHistoryMapper.class) with new MyPlaceHistoryMapperImpl().

I also added a quick check of @Prefix annotations, but it'll only emit warnings and won't fail the build.

The JAR is available in Sonatype OSSRH snapshots repository at net.ltgt.gwt:gwt-places:1.0-SNAPSHOT; its only dependency is gwt-user.

It's an annotation processor, so usage will depend on your build tool. Ideally you'd put it (along with gwt-user) in your "processor path" (e.g. using the 'apt' configuration in Gradle with my net.ltgt.apt plugin), but if you can't (e.g. if you're using Maven), just add it to your compile classpath.

Note that I only verified that the tests passed, I've not used it anywhere (yet).

Re: Roadmap Question for GWT 3.0

@jens @umit

Thank you very much for this insight.

Best Regards

On Tue, Jun 30, 2015 at 9:44 AM, Ümit Seren <uemit.seren@gmail.com> wrote:

In addition to what Jens said:
If possible, go Restful. it makes it much easier to later add non-GWT clients and also forces you to think about your domain model as resources (might lead to a clean API).

I guess once Elemental 2.0 is released (AFAIK along the lines with GWT 3.0) you could either use XMLHttpRequest or fetch (https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en) if you don't mind to use a polyfill for non-supported browser (maybe at that point all the evergreen browsers already support it natively) or use a higher abstraction (like RestyGWT, etc)

On Tuesday, June 30, 2015 at 12:42:51 PM UTC+2, Ed wrote:
@jens

Is there any downside to Request Builder? Possible deprecation in GWT 3.0?

Best Regards

Ed

On Mon, Jun 29, 2015 at 1:43 PM, Ed <ej1...@gmail.com> wrote:
Thanks Jens, Great response, gives our devs something to learn.

On Mon, Jun 29, 2015 at 12:55 PM, Jens <jens.ne...@gmail.com> wrote:

1. GWT.create

<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection and System.getProperty() to build the Dagger dependency graph based on your deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact including a GWT module: https://github.com/google/dagger/pull/119

2. RPC

Anything that generates code in a way that is compatible with annotation processors so they can migrate to APT in the future. I guess you need to ask maintainers of your preferred alternatives and hear what they say. Regardless of GWT 3.0 I would never really use GWT-RPC again because things like RPC policy files, "do not use interfaces in serializable types" and that it is hard to consume outside of GWT are annoying.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

In addition to what Jens said:
If possible, go Restful. it makes it much easier to later add non-GWT clients and also forces you to think about your domain model as resources (might lead to a clean API).

I guess once Elemental 2.0 is released (AFAIK along the lines with GWT 3.0) you could either use XMLHttpRequest or fetch (https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en) if you don't mind to use a polyfill for non-supported browser (maybe at that point all the evergreen browsers already support it natively) or use a higher abstraction (like RestyGWT, etc)

On Tuesday, June 30, 2015 at 12:42:51 PM UTC+2, Ed wrote:

@jens

Is there any downside to Request Builder? Possible deprecation in GWT 3.0?

Best Regards

Ed

On Mon, Jun 29, 2015 at 1:43 PM, Ed <ej1...@gmail.com> wrote:
Thanks Jens, Great response, gives our devs something to learn.

On Mon, Jun 29, 2015 at 12:55 PM, Jens <jens.ne...@gmail.com> wrote:

1. GWT.create

<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection and System.getProperty() to build the Dagger dependency graph based on your deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact including a GWT module: https://github.com/google/dagger/pull/119

2. RPC

Anything that generates code in a way that is compatible with annotation processors so they can migrate to APT in the future. I guess you need to ask maintainers of your preferred alternatives and hear what they say. Regardless of GWT 3.0 I would never really use GWT-RPC again because things like RPC policy files, "do not use interfaces in serializable types" and that it is hard to consume outside of GWT are annoying.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

Is there any downside to Request Builder? Possible deprecation in GWT 3.0?

Well the internally used XMLHttpRequest / Timer classes would need to be ported to JsInterop of course because they use JSNI.

There are some general to consider with RequestBuilder as well:

- It is quite low level

- RequestCallback is not Java8 friendly (lambda / method references) as it is not a SAM interface.

- for now does not support XHR 2 (ArrayBuffer, Blob, Document response types) out of the box

-- J.

Re: Roadmap Question for GWT 3.0

@jens

Is there any downside to Request Builder? Possible deprecation in GWT 3.0?

Best Regards

On Mon, Jun 29, 2015 at 1:43 PM, Ed <ej197us@gmail.com> wrote:

Thanks Jens, Great response, gives our devs something to learn.

On Mon, Jun 29, 2015 at 12:55 PM, Jens <jens.nehlmeier@gmail.com> wrote:

1. GWT.create

<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection and System.getProperty() to build the Dagger dependency graph based on your deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact including a GWT module: https://github.com/google/dagger/pull/119

2. RPC

Anything that generates code in a way that is compatible with annotation processors so they can migrate to APT in the future. I guess you need to ask maintainers of your preferred alternatives and hear what they say. Regardless of GWT 3.0 I would never really use GWT-RPC again because things like RPC policy files, "do not use interfaces in serializable types" and that it is hard to consume outside of GWT are annoying.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Monday, June 29, 2015

Re: How to Remote Logging without using RPC?

Thank you.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: How to Remote Logging without using RPC?

Remote logging example using request factory https://github.com/gwtproject/gwt/blob/master/samples/dynatablerf/src/main/java/com/google/gwt/sample/dynatablerf/client/DynaTableRf.java#L73

On Monday, June 29, 2015 at 9:27:59 PM UTC+2, Chak Lai wrote:

In the GWT application that I am working on, it is setup to remote-logging with any uncaught exceptions via SerializableThrowable >> RPC >> StackTraceDeobfuscator ...

Is there any documentation on how to do it without using RPC?

I have search the Internet but is seems most of the documentation are using RPC.

How to Remote Logging without using RPC?

In the GWT application that I am working on, it is setup to remote-logging with any uncaught exceptions via SerializableThrowable >> RPC >> StackTraceDeobfuscator ...

Is there any documentation on how to do it without using RPC?

I have search the Internet but is seems most of the documentation are using RPC.

Re: Roadmap Question for GWT 3.0

Thanks Jens, Great response, gives our devs something to learn.

On Mon, Jun 29, 2015 at 12:55 PM, Jens <jens.nehlmeier@gmail.com> wrote:

1. GWT.create

<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection and System.getProperty() to build the Dagger dependency graph based on your deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact including a GWT module: https://github.com/google/dagger/pull/119

2. RPC

Anything that generates code in a way that is compatible with annotation processors so they can migrate to APT in the future. I guess you need to ask maintainers of your preferred alternatives and hear what they say. Regardless of GWT 3.0 I would never really use GWT-RPC again because things like RPC policy files, "do not use interfaces in serializable types" and that it is hard to consume outside of GWT are annoying.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

1. GWT.create

<generate-with>: Annotation processors

<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection and System.getProperty() to build the Dagger dependency graph based on your deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact including a GWT module: https://github.com/google/dagger/pull/119

2. RPC

Anything that generates code in a way that is compatible with annotation processors so they can migrate to APT in the future. I guess you need to ask maintainers of your preferred alternatives and hear what they say. Regardless of GWT 3.0 I would never really use GWT-RPC again because things like RPC policy files, "do not use interfaces in serializable types" and that it is hard to consume outside of GWT are annoying.

-- J.

Roadmap Question for GWT 3.0

If I wanted to start now for the the GWT 3.0 release, what would be the best mechanism to replace:

1. GWT.create

2. RPC

We starting a refactor of existing code, and would like some foresight into this matter.

Thanks

Re: Important videos from GWT Meet-up 2015

On thing I'd like to see on GWT 3.0 and beyond is the reduction (or complete avoidance) of the "Not invented here syndrome" from Google:

Using a standard build tool which integrates well with Maven repositories - and don't force the end user to switch build tools just because
Using GitHub for pull requests - and nothing more than that - to allow easy community contributions
Allow the user to integrate with any CSS processor he wants, such as less, sass or any other
A HTML template engine that uses input as close as possible to the real HTML (like Errai does)