[gwt-contrib] Re: event code review, part 1.
Ray, it's pretty clear that we're going to land with the ability to instantiate and dispatch events in pure Java in tact, but Emily and I will need to document just why and how it's necessary, and beef up testing around the two paths. Offline I've already promised Kelly a couple of write ups on GWT and unit testing, mocking, DI... rjrjr On Thu, Nov 6, 2008 at 11:22 AM, 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=issue3083branch=/branches/1_6_clean_eventsreviews. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: event code review, part 1.
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. Actually the dispatch is already optimized for the JS case, the argument here is whether we need to continue to support the raw Java case as well. Cheers, Emily -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=issue3083branch=/branches/1_6_clean_eventsreviews. -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: event code review, part 1.
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=issue3083branch=/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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: event code review, part 1.
+1 to Kelly's sentiment @Ray C: Since you're probably doing more of this highly cross-compilable code than anyone else, we're keen to get your participation in helping formalize a set of design rules related to the portability/testability issue. We definitely don't want to break the rockin' cool stuff you're doing; we just want to make it all very intentional. On Thu, Nov 6, 2008 at 3:41 PM, Kelly Norton [EMAIL PROTECTED] wrote: 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=issue3083branch=/branches/1_6_clean_eventsreviews. -- 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 -~--~~~~--~~--~--~---
