Re: [gwt-contrib] JSIO vs Overlay Types
The author of that library has plans to migrate to overlay types. We've got a change branch going on http://code.google.com/p/gwt-google-apis under changes/vinays/. http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3 On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks for the feedback. The reason I'm not using the official Maps API is that I need to use version 3 of the JavaScript API, which isn't supported by the GWT Google APIs project yet. The more developed of the GWT Maps Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for everything, rather than overlay types, so I'm concerned about performance in the case that lots (hundreds or so) of objects are being rendered on the map. At the moment it's looking like I'll contribute some changes there. Thanks again, Daniel On 7 July 2010 03:20, Eric Ayers zun...@google.com wrote: Overlay types are the way to go. The gwt-maps API use jsio because it predates overlay types. On Jul 6, 2010 11:18 AM, John Tamplin j...@google.com wrote: On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell daniel.r.b...@gmail.com wrote: I have a question for you about Overlay Types and the JSIO library. I'm working on a GWT interface to the Google Maps JavaScript API, and am wondering about the difference in performance between the two approaches. With JSIO I've been using wrapper objects that each contain an instance of a JavaScriptObject being wrapped, and contain a reference to a singleton instance of the flyweight wrapper. My guess is that the performance would be better if I used Overlay Types instead, but I am just guessing. Do you know (roughly) what the difference in performance is between the two approaches? First question - why aren't you using the official GWT APIs for Maps instead of writing your own? http://code.google.com/p/gwt-google-apis/ If there is something you need that isn't included, why not contribute to that rather than create your own from scratch? Overlay types are a bit more efficient and don't require a generator running which makes DevMode faster, but I don't think there is a lot of difference. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] JSIO vs Overlay Types
Oh, and I meant to say that your contributions are welcome! On Wed, Jul 7, 2010 at 7:38 AM, Eric Ayers zun...@google.com wrote: The author of that library has plans to migrate to overlay types. We've got a change branch going on http://code.google.com/p/gwt-google-apis under changes/vinays/. http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3 On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks for the feedback. The reason I'm not using the official Maps API is that I need to use version 3 of the JavaScript API, which isn't supported by the GWT Google APIs project yet. The more developed of the GWT Maps Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for everything, rather than overlay types, so I'm concerned about performance in the case that lots (hundreds or so) of objects are being rendered on the map. At the moment it's looking like I'll contribute some changes there. Thanks again, Daniel On 7 July 2010 03:20, Eric Ayers zun...@google.com wrote: Overlay types are the way to go. The gwt-maps API use jsio because it predates overlay types. On Jul 6, 2010 11:18 AM, John Tamplin j...@google.com wrote: On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell daniel.r.b...@gmail.com wrote: I have a question for you about Overlay Types and the JSIO library. I'm working on a GWT interface to the Google Maps JavaScript API, and am wondering about the difference in performance between the two approaches. With JSIO I've been using wrapper objects that each contain an instance of a JavaScriptObject being wrapped, and contain a reference to a singleton instance of the flyweight wrapper. My guess is that the performance would be better if I used Overlay Types instead, but I am just guessing. Do you know (roughly) what the difference in performance is between the two approaches? First question - why aren't you using the official GWT APIs for Maps instead of writing your own? http://code.google.com/p/gwt-google-apis/ If there is something you need that isn't included, why not contribute to that rather than create your own from scratch? Overlay types are a bit more efficient and don't require a generator running which makes DevMode faster, but I don't think there is a lot of difference. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add support for creating Grid elements using UiBinder. (issue154810)
ping... http://gwt-code-reviews.appspot.com/154810/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] JSIO vs Overlay Types
Thanks Eric, Vinay. Which project would you prefer I contributed the code to? So far I've I've been working with a clone of the repo at gwt-google-maps-v3, but I'm happy to switch to using the gwt-google-apis branch if that will help with migration and API stability. On 7 July 2010 21:50, Vinay Sekhri vin...@google.com wrote: Hi Daniel, I was about to respond to you on different thread you wrote to me. Right now I am in process of adding new feature (without JSIO dependency) in my existing project and copy same to gwt-google-apis project. Once I understand things well, we will be in a better position to merge in official API -- this might take some time. On your question to contributing to gwt-google-maps-v3 : you create a clone of the existing repo, make your changes and send me the patches. Once we are on the same page on coding/design style, I can add you as a contributor to the project. Eric, I am running these two projects in parallel for now because I do not want existing user to suffer because this merge. Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 5:08 PM, Eric Ayers zun...@google.com wrote: The author of that library has plans to migrate to overlay types. We've got a change branch going on http://code.google.com/p/gwt-google-apis under changes/vinays/. http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3 On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks for the feedback. The reason I'm not using the official Maps API is that I need to use version 3 of the JavaScript API, which isn't supported by the GWT Google APIs project yet. The more developed of the GWT Maps Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for everything, rather than overlay types, so I'm concerned about performance in the case that lots (hundreds or so) of objects are being rendered on the map. At the moment it's looking like I'll contribute some changes there. Thanks again, Daniel On 7 July 2010 03:20, Eric Ayers zun...@google.com wrote: Overlay types are the way to go. The gwt-maps API use jsio because it predates overlay types. On Jul 6, 2010 11:18 AM, John Tamplin j...@google.com wrote: On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell daniel.r.b...@gmail.com wrote: I have a question for you about Overlay Types and the JSIO library. I'm working on a GWT interface to the Google Maps JavaScript API, and am wondering about the difference in performance between the two approaches. With JSIO I've been using wrapper objects that each contain an instance of a JavaScriptObject being wrapped, and contain a reference to a singleton instance of the flyweight wrapper. My guess is that the performance would be better if I used Overlay Types instead, but I am just guessing. Do you know (roughly) what the difference in performance is between the two approaches? First question - why aren't you using the official GWT APIs for Maps instead of writing your own? http://code.google.com/p/gwt-google-apis/ If there is something you need that isn't included, why not contribute to that rather than create your own from scratch? Overlay types are a bit more efficient and don't require a generator running which makes DevMode faster, but I don't think there is a lot of difference. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Allow RPC for unmodificable collections (issue620805)
Reviewers: jat, Description: Allow RPC for unmodificable collections Please review this at http://gwt-code-reviews.appspot.com/620805/show Affected files: M user/src/com/google/gwt/user/client/rpc/core/java/util/Collections.java M user/src/com/google/gwt/user/client/rpc/core/java/util/TreeSet_CustomFieldSerializer.java M user/super/com/google/gwt/emul/java/util/Collections.java M user/test/com/google/gwt/emultest/java/util/CollectionsTest.java M user/test/com/google/gwt/user/client/rpc/CollectionsTest.java M user/test/com/google/gwt/user/client/rpc/CollectionsTestService.java M user/test/com/google/gwt/user/client/rpc/CollectionsTestServiceAsync.java M user/test/com/google/gwt/user/client/rpc/TestSetFactory.java M user/test/com/google/gwt/user/client/rpc/TestSetValidator.java M user/test/com/google/gwt/user/server/rpc/CollectionsTestServiceImpl.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Avira and HTML/CryptedGen (once again)
In March 2010 Matt Mastracci reported problems with the Avira heuristics misdetecting GWT-generated files as Crypted/Gen malware: http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/cb7ce70ff8af204/f257d2e0f93ba039 Avira has reacted and modified their heuristics. But it turns out that their detection algorithms are now worse than they were before. You can read my report on this here: https://sourceforge.net/apps/mediawiki/protoreto/index.php?title=Avira_AntiVir_triggers_false_alarms_in_GWT-generated_JavaScript -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] JSIO vs Overlay Types
Daniel, I guess it would make sense for you to contribute code at gwt-google-apis vinays branch. Plan is to convert the existing JSIO dependent code to Overlay types and write test cases for the same. You may also opt to write missing types from JS API using Overlay types. Let me know what you would like to start with and whats the best way to sync-up between you and me? Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 7:24 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks Eric, Vinay. Which project would you prefer I contributed the code to? So far I've I've been working with a clone of the repo at gwt-google-maps-v3, but I'm happy to switch to using the gwt-google-apis branch if that will help with migration and API stability. On 7 July 2010 21:50, Vinay Sekhri vin...@google.com wrote: Hi Daniel, I was about to respond to you on different thread you wrote to me. Right now I am in process of adding new feature (without JSIO dependency) in my existing project and copy same to gwt-google-apis project. Once I understand things well, we will be in a better position to merge in official API -- this might take some time. On your question to contributing to gwt-google-maps-v3 : you create a clone of the existing repo, make your changes and send me the patches. Once we are on the same page on coding/design style, I can add you as a contributor to the project. Eric, I am running these two projects in parallel for now because I do not want existing user to suffer because this merge. Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 5:08 PM, Eric Ayers zun...@google.com wrote: The author of that library has plans to migrate to overlay types. We've got a change branch going on http://code.google.com/p/gwt-google-apis under changes/vinays/. http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3 On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks for the feedback. The reason I'm not using the official Maps API is that I need to use version 3 of the JavaScript API, which isn't supported by the GWT Google APIs project yet. The more developed of the GWT Maps Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for everything, rather than overlay types, so I'm concerned about performance in the case that lots (hundreds or so) of objects are being rendered on the map. At the moment it's looking like I'll contribute some changes there. Thanks again, Daniel On 7 July 2010 03:20, Eric Ayers zun...@google.com wrote: Overlay types are the way to go. The gwt-maps API use jsio because it predates overlay types. On Jul 6, 2010 11:18 AM, John Tamplin j...@google.com wrote: On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell daniel.r.b...@gmail.com wrote: I have a question for you about Overlay Types and the JSIO library. I'm working on a GWT interface to the Google Maps JavaScript API, and am wondering about the difference in performance between the two approaches. With JSIO I've been using wrapper objects that each contain an instance of a JavaScriptObject being wrapped, and contain a reference to a singleton instance of the flyweight wrapper. My guess is that the performance would be better if I used Overlay Types instead, but I am just guessing. Do you know (roughly) what the difference in performance is between the two approaches? First question - why aren't you using the official GWT APIs for Maps instead of writing your own? http://code.google.com/p/gwt-google-apis/ If there is something you need that isn't included, why not contribute to that rather than create your own from scratch? Overlay types are a bit more efficient and don't require a generator running which makes DevMode faster, but I don't think there is a lot of difference. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Allow RPC for unmodificable collections (issue620805)
http://gwt-code-reviews.appspot.com/620805/diff/1/2
File
user/src/com/google/gwt/user/client/rpc/core/java/util/Collections.java
(right):
http://gwt-code-reviews.appspot.com/620805/diff/1/2#newcode135
user/src/com/google/gwt/user/client/rpc/core/java/util/Collections.java:135:
/**
So how does this work with server-side implementation classes? Aren't
they going to need custom serializers for whatever internal classes the
particular JVM uses?
Previously we said the solution was RPC-by-interface, which would allow
you to say that the default implementation for any unknown List subtype
is ArrayList, for example, though obviously that breaks a List view onto
some larger data structure.
http://gwt-code-reviews.appspot.com/620805/diff/1/4
File user/super/com/google/gwt/emul/java/util/Collections.java (right):
http://gwt-code-reviews.appspot.com/620805/diff/1/4#newcode141
user/super/com/google/gwt/emul/java/util/Collections.java:141: private
static final class SingletonMapK, V extends AbstractMapK, V
implements Serializable {
Javadoc explaining when this is used.
http://gwt-code-reviews.appspot.com/620805/diff/1/6
File user/test/com/google/gwt/user/client/rpc/CollectionsTest.java
(right):
http://gwt-code-reviews.appspot.com/620805/diff/1/6#newcode590
user/test/com/google/gwt/user/client/rpc/CollectionsTest.java:590:
service.echoSingletonMap(TestSetFactory.createSingletonMap(),
Shouldn't these have a method where the various internal collection
types are created on the server?
http://gwt-code-reviews.appspot.com/620805/diff/1/11
File
user/test/com/google/gwt/user/server/rpc/CollectionsTestServiceImpl.java
(right):
http://gwt-code-reviews.appspot.com/620805/diff/1/11#newcode450
user/test/com/google/gwt/user/server/rpc/CollectionsTestServiceImpl.java:450:
return value;
Instead of returning the same value, what about creating a new one on
the server from the one supplied, so we can test freshly-created
instances?
http://gwt-code-reviews.appspot.com/620805/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Optimize JsFunctionClusterer with faster edit distance algorithms (issue669801)
LGTM http://gwt-code-reviews.appspot.com/669801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Reorder outer 'this' constructor arguments to come before user arguments. (issue675801)
Reviewers: Lex, tobyr, Description: The main purpose of this change is to remove the impedance mismatch between our constructor argument order, and the argument order for JSNI ::new() invocations. Our constructors put the synthetic this args after user args, JSNI ::new() puts the args before user args. Once this impedance mismatch is cleared up, in a follow up change I plan to remove the static synthetic 'new' methods in favor of targeting the constructors directly. Please review this at http://gwt-code-reviews.appspot.com/675801/show Affected files: M dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.java M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] JSIO vs Overlay Types
Hi Vinay, That sounds good. I'll probably start with converting some of the code using JSIO to use overlay types, because that's what I'm using for my current project. Regarding testing, it seems that the tests used in the gwt-google-apis Maps v2 API use the gwt-google-apis AjaxLoader implementation to load the API, but that the underlying AjaxLoader only supports Maps v2. Do you know if there are plans to add v3 support to the AjaxLoader? Thanks, Daniel On 8 July 2010 01:35, Vinay Sekhri vin...@google.com wrote: Daniel, I guess it would make sense for you to contribute code at gwt-google-apis vinays branch. Plan is to convert the existing JSIO dependent code to Overlay types and write test cases for the same. You may also opt to write missing types from JS API using Overlay types. Let me know what you would like to start with and whats the best way to sync-up between you and me? Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 7:24 PM, Daniel Bell daniel.r.b...@gmail.comwrote: Thanks Eric, Vinay. Which project would you prefer I contributed the code to? So far I've I've been working with a clone of the repo at gwt-google-maps-v3, but I'm happy to switch to using the gwt-google-apis branch if that will help with migration and API stability. On 7 July 2010 21:50, Vinay Sekhri vin...@google.com wrote: Hi Daniel, I was about to respond to you on different thread you wrote to me. Right now I am in process of adding new feature (without JSIO dependency) in my existing project and copy same to gwt-google-apis project. Once I understand things well, we will be in a better position to merge in official API -- this might take some time. On your question to contributing to gwt-google-maps-v3 : you create a clone of the existing repo, make your changes and send me the patches. Once we are on the same page on coding/design style, I can add you as a contributor to the project. Eric, I am running these two projects in parallel for now because I do not want existing user to suffer because this merge. Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 5:08 PM, Eric Ayers zun...@google.com wrote: The author of that library has plans to migrate to overlay types. We've got a change branch going on http://code.google.com/p/gwt-google-apis under changes/vinays/. http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3 On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks for the feedback. The reason I'm not using the official Maps API is that I need to use version 3 of the JavaScript API, which isn't supported by the GWT Google APIs project yet. The more developed of the GWT Maps Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for everything, rather than overlay types, so I'm concerned about performance in the case that lots (hundreds or so) of objects are being rendered on the map. At the moment it's looking like I'll contribute some changes there. Thanks again, Daniel On 7 July 2010 03:20, Eric Ayers zun...@google.com wrote: Overlay types are the way to go. The gwt-maps API use jsio because it predates overlay types. On Jul 6, 2010 11:18 AM, John Tamplin j...@google.com wrote: On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell daniel.r.b...@gmail.com wrote: I have a question for you about Overlay Types and the JSIO library. I'm working on a GWT interface to the Google Maps JavaScript API, and am wondering about the difference in performance between the two approaches. With JSIO I've been using wrapper objects that each contain an instance of a JavaScriptObject being wrapped, and contain a reference to a singleton instance of the flyweight wrapper. My guess is that the performance would be better if I used Overlay Types instead, but I am just guessing. Do you know (roughly) what the difference in performance is between the two approaches? First question - why aren't you using the official GWT APIs for Maps instead of writing your own? http://code.google.com/p/gwt-google-apis/ If there is something you need that isn't included, why not contribute to that rather than create your own from scratch? Overlay types are a bit more efficient and don't require a generator running which makes DevMode faster, but I don't think there is a lot of difference. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA --
Re: [gwt-contrib] JSIO vs Overlay Types
There are reports of success loading the v3 API with the AJAX Loader (aka Common Loader). The AjaxLoader Java support is API agnostic. You should be able to provide the same parameters to AjaxLoader.loadApi() as described in the forum post below: http://www.devcomments.com/Loading-v3-with-google-load-at93219.htm From a performance perspective, the common loader will be slower than just including the script tag to load the API. I think that is why it isn't being promoted heavily. That and the lack of need for an API key makes it less compelling to use the AjaxLoader classes. You could write a simple script tag injector for the v3 Maps API that works like the AjaxLoader class does if you wanted the delayed load of the Maps API from GWT code. The simplest thing to do is to just add the script tag in your hosted page, though. On Wed, Jul 7, 2010 at 8:49 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Hi Vinay, That sounds good. I'll probably start with converting some of the code using JSIO to use overlay types, because that's what I'm using for my current project. Regarding testing, it seems that the tests used in the gwt-google-apis Maps v2 API use the gwt-google-apis AjaxLoader implementation to load the API, but that the underlying AjaxLoader only supports Maps v2. Do you know if there are plans to add v3 support to the AjaxLoader? Thanks, Daniel On 8 July 2010 01:35, Vinay Sekhri vin...@google.com wrote: Daniel, I guess it would make sense for you to contribute code at gwt-google-apis vinays branch. Plan is to convert the existing JSIO dependent code to Overlay types and write test cases for the same. You may also opt to write missing types from JS API using Overlay types. Let me know what you would like to start with and whats the best way to sync-up between you and me? Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 7:24 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks Eric, Vinay. Which project would you prefer I contributed the code to? So far I've I've been working with a clone of the repo at gwt-google-maps-v3, but I'm happy to switch to using the gwt-google-apis branch if that will help with migration and API stability. On 7 July 2010 21:50, Vinay Sekhri vin...@google.com wrote: Hi Daniel, I was about to respond to you on different thread you wrote to me. Right now I am in process of adding new feature (without JSIO dependency) in my existing project and copy same to gwt-google-apis project. Once I understand things well, we will be in a better position to merge in official API -- this might take some time. On your question to contributing to gwt-google-maps-v3 : you create a clone of the existing repo, make your changes and send me the patches. Once we are on the same page on coding/design style, I can add you as a contributor to the project. Eric, I am running these two projects in parallel for now because I do not want existing user to suffer because this merge. Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 5:08 PM, Eric Ayers zun...@google.com wrote: The author of that library has plans to migrate to overlay types. We've got a change branch going on http://code.google.com/p/gwt-google-apis under changes/vinays/. http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3 On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks for the feedback. The reason I'm not using the official Maps API is that I need to use version 3 of the JavaScript API, which isn't supported by the GWT Google APIs project yet. The more developed of the GWT Maps Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for everything, rather than overlay types, so I'm concerned about performance in the case that lots (hundreds or so) of objects are being rendered on the map. At the moment it's looking like I'll contribute some changes there. Thanks again, Daniel On 7 July 2010 03:20, Eric Ayers zun...@google.com wrote: Overlay types are the way to go. The gwt-maps API use jsio because it predates overlay types. On Jul 6, 2010 11:18 AM, John Tamplin j...@google.com wrote: On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell daniel.r.b...@gmail.com wrote: I have a question for you about Overlay Types and the JSIO library. I'm working on a GWT interface to the Google Maps JavaScript API, and am wondering about the difference in performance between the two approaches. With JSIO I've been using wrapper objects that each contain an instance of a JavaScriptObject being wrapped, and contain a reference to a singleton instance of the flyweight wrapper. My guess is that the performance would be better if I used Overlay Types instead, but I am just guessing. Do you know
[gwt-contrib] JSNI ::new() now targets constructors directly (issue676801)
Reviewers: Lex, tobyr,
Description:
Follow-on to http://gwt-code-reviews.appspot.com/675801/show
This patch removes the extra hop through a synthetic static 'new'
function that is currently used for implementing JSNI ::new()
invocations.
In the 99% case, the JsInvocation is replaced with a JsNew operation on
the target constructor. In rare cases where the constructor is not
immediately invoked, a tear off function is creation which performs the
new op internally.
Examples:
test.Foo::new()(); - new test_Foo();
var factory = test.Foo::new(); - var factory = function() { return new
test_Foo(); };
Please review this at http://gwt-code-reviews.appspot.com/676801/show
Affected files:
M dev/core/src/com/google/gwt/dev/jjs/ast/JVisitor.java
M dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.java
M dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
M dev/core/src/com/google/gwt/dev/jjs/impl/JsniRefLookup.java
M dev/core/test/com/google/gwt/dev/jjs/impl/JsniRefLookupTest.java
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] JSIO vs Overlay Types
Thanks for the suggestions. I like the script tag injector idea. I'm currently using AjaxLoader in to load the v2 API when the user navigates to the page with the map in it. I did try the using AjaxLoader.loadApi() to get the Maps v3 API (using the same params described in the forum post you mentioned), but the map did not load in IE, and there were exceptions in Firefox, so I just used the script tag. Maybe I'll revisit that later. On 8 July 2010 11:29, Eric Ayers zun...@google.com wrote: There are reports of success loading the v3 API with the AJAX Loader (aka Common Loader). The AjaxLoader Java support is API agnostic. You should be able to provide the same parameters to AjaxLoader.loadApi() as described in the forum post below: http://www.devcomments.com/Loading-v3-with-google-load-at93219.htm From a performance perspective, the common loader will be slower than just including the script tag to load the API. I think that is why it isn't being promoted heavily. That and the lack of need for an API key makes it less compelling to use the AjaxLoader classes. You could write a simple script tag injector for the v3 Maps API that works like the AjaxLoader class does if you wanted the delayed load of the Maps API from GWT code. The simplest thing to do is to just add the script tag in your hosted page, though. On Wed, Jul 7, 2010 at 8:49 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Hi Vinay, That sounds good. I'll probably start with converting some of the code using JSIO to use overlay types, because that's what I'm using for my current project. Regarding testing, it seems that the tests used in the gwt-google-apis Maps v2 API use the gwt-google-apis AjaxLoader implementation to load the API, but that the underlying AjaxLoader only supports Maps v2. Do you know if there are plans to add v3 support to the AjaxLoader? Thanks, Daniel On 8 July 2010 01:35, Vinay Sekhri vin...@google.com wrote: Daniel, I guess it would make sense for you to contribute code at gwt-google-apis vinays branch. Plan is to convert the existing JSIO dependent code to Overlay types and write test cases for the same. You may also opt to write missing types from JS API using Overlay types. Let me know what you would like to start with and whats the best way to sync-up between you and me? Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 7:24 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks Eric, Vinay. Which project would you prefer I contributed the code to? So far I've I've been working with a clone of the repo at gwt-google-maps-v3, but I'm happy to switch to using the gwt-google-apis branch if that will help with migration and API stability. On 7 July 2010 21:50, Vinay Sekhri vin...@google.com wrote: Hi Daniel, I was about to respond to you on different thread you wrote to me. Right now I am in process of adding new feature (without JSIO dependency) in my existing project and copy same to gwt-google-apis project. Once I understand things well, we will be in a better position to merge in official API -- this might take some time. On your question to contributing to gwt-google-maps-v3 : you create a clone of the existing repo, make your changes and send me the patches. Once we are on the same page on coding/design style, I can add you as a contributor to the project. Eric, I am running these two projects in parallel for now because I do not want existing user to suffer because this merge. Thanks! -- Vinay Sekhri Google India +91.124.451.2822 Direct +91.9910.195.609 Mobile On Wed, Jul 7, 2010 at 5:08 PM, Eric Ayers zun...@google.com wrote: The author of that library has plans to migrate to overlay types. We've got a change branch going on http://code.google.com/p/gwt-google-apis under changes/vinays/. http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3 On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell daniel.r.b...@gmail.com wrote: Thanks for the feedback. The reason I'm not using the official Maps API is that I need to use version 3 of the JavaScript API, which isn't supported by the GWT Google APIs project yet. The more developed of the GWT Maps Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for everything, rather than overlay types, so I'm concerned about performance in the case that lots (hundreds or so) of objects are being rendered on the map. At the moment it's looking like I'll contribute some changes there. Thanks again, Daniel On 7 July 2010 03:20, Eric Ayers zun...@google.com wrote: Overlay types are the way to go. The gwt-maps API use jsio because it predates overlay types. On Jul 6, 2010 11:18 AM, John Tamplin j...@google.com wrote: On Tue, Jul 6, 2010 at
