Dear GWT'ers,
I'd like to propose a new GWT compiler transformation mechanism
involving Async calls.
I am working on a GWT API for accessing the HTML5 Database feature[1]
in an OpenSource project[2]. The W3C Web Database API[3] is translated
quite literally to a Java equivalent, involving
Check this thread:
http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/4239559936d327e7/
On 1 nov, 11:01, Bart Guijt bgu...@gmail.com wrote:
Dear GWT'ers,
I'd like to propose a new GWT compiler transformation mechanism
involving Async calls.
I am working
Exactly!
I couldn't imagine being the first to propose something like this.
Although I concur with Bob Vawter's comment, I still think there's a
place for a compiler transformation like this. The proposal is not to
meet incompetence levels of Java programmers, it is to enable existing
On Sun, Nov 1, 2009 at 10:38 AM, Bart Guijt bgu...@gmail.com wrote:
Although I concur with Bob Vawter's comment, I still think there's a
place for a compiler transformation like this. The proposal is not to
meet incompetence levels of Java programmers, it is to enable existing
Java libraries
Revision: 6576
Author: jlaba...@google.com
Date: Sun Nov 1 08:30:34 2009
Log: Adding properties to specify test args based on the compile type
(dev/web and remote/selenium). Also readding the ability to specify test
args on a test target basis, which was removed during the gwt 2.0 merge.
On 1 nov 2009, at 1 nov, 17:24, John Tamplin wrote:
On Sun, Nov 1, 2009 at 10:38 AM, Bart Guijt bgu...@gmail.com wrote:
Although I concur with Bob Vawter's comment, I still think there's a
place for a compiler transformation like this. The proposal is not to
meet incompetence levels of Java
Revision: 6577
Author: jlaba...@google.com
Date: Sun Nov 1 08:33:32 2009
Log: tr...@6576 was merged into this branch
Allows test args to be specified per compile type.
svn merge --ignore-ancestry -c 6576
https://google-web-toolkit.googlecode.com/svn/trunk .
Patch by: jlabanca
Comment by gwtdevel...@gmail.com:
@tamplinjohn: I managed to OOPHM to work in XUL by creating a new Linker
See
http://www.gdevelop.com/w/2009/10/30/using-oophm-to-develop-xul-applications/
For more information:
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
I find that there are two sources of a lot of boilerplate code for the
async stuff I work on:
1. State machines
2. Coordinating multiple asynchronous events (ie: timers, multiple
inflight requests and user events)
For #1, the code usually ends up as a set of enums for simple states
