Ray C., No worries. We are planning to land a pure java code path through event dispatch code. My real objection in the review, which Emily and Ray forced out of me, is that we have never enumerated goals and use cases around sharing GWT-java code with other Java contexts. I want to make sure we have a good sense of what we want to accomplish with these because it is very easy to continue to slip in a change here and a change there to the point where you have no idea what part of the library can run in what context.
So the plan is to land the implementation as is, but officially, the fact that there is a java code path through the event dispatch is really just happenstance. Meaning that we're not committing to support it quite yet. Ray Ryan is going to assemble a bit more vision around testability and mockability of GWT apps and libraries so that going forward we'll have a lot more guidance when we face these decisions. /kel On Thu, Nov 6, 2008 at 2:22 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote: > Emily, > The issue of sharing the event handlers in non-GWT code is a > virtual showstopper for me. One of the initial reasons I was drawn to > GWT was the ability to share code between client and server, and now > I've taken that to Flash and Android as well. Two things: > > 1) I run both GWT unit tests and regular unit tests. Smoke tests and > shared functionality or non-JSNI code is typically JUnit tested. There > are a couple of reasons for this, such as inability to run GWT tests > under Maven, JUnit tests running much faster and not requiring > XWindows to be running on our build box, differences between hosted > mode on Linux/Windows/IE that make it hard to test logic without > swapping implementations using deferred binding. Our build process > allows us to do fast JUnit tests while developing, and then the > continuous integration server launches GWT tests on 3 separate > machines in the background. > > 2) The core logic of my GWT code is shared in my Android version, as > well as my Servlet/Applet version. The current design allows me to > create something like a 'zoom event' and map it to different > dispatchers on Android, Browser, or Servlet (e.g. the servlet can fall > back to non-Javascript old-style MapQuest-like interface) > > If you are going to remove the HashMap version in favor of a pure JS > registry, might I suggest using a module property to do this so that I > can override it and get back the original HashMap implementation? > Otherwise, I'd be forced to fork or override GWT which would be a huge > PITA, and could add to code bloat for me if I am forced to duplicate > functionality. > > Overall, I don't see any reason for not using HashMap except > performance, and while I could see a speedup in the event dispatching, > and better memory efficiency, I'm not sure event dispatching is a > hot-spot in current application code. > > -Ray > > On Thu, Nov 6, 2008 at 7:45 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: >> Thanks a million for an awesome review! There are a few points that need >> discussion, I've logged them >> under >> http://code.google.com/p/google-web-toolkit/source/branch?spec=issue3083&branch=/branches/1_6_clean_events >> reviews. >> >> >> >> >> >> > -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
