For the next installment of the Google API Library for GWT<http://code.google.com/p/gwt-google-apis/>, we are working to add support for the Google Maps API and the Google AJAX Search API. This email is to let you know about a milestone build that we've produced to get your feedback on the API and see how well it works for your needs. This is not intended to be used for production, there may be breaking API changes before a true release and please report any bugs over on the issue tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
hi Miguel and all Google API Library for GWT Team, great work, Even if I played only with AJAX Search API wrapper yesterday and that was really a pleasure to play with this beta api (I left maps for few other days to play with them), I'm already quite experienced with your way of binding JS to Java by testing Ajax Feed Api project and Gears to some extent so that was really easy to use new libraries. Everything works the way I would expect - however I'm just wondering what are your plans with that api because there is couple of things that took my attention (again AJAX Search API only): - it looks api will be designed to strictly UI based use via GSearchControl widget only - it looks I cannot use GSearch objects directly becase I"m not able to bind any results to SearchResultsListener What is "setSearchCompleteCallbock" you've wrote??? (I know you know what I'm wrote here). I guess the way putting me off using my custom UI elements for results because I will always get "JavaScript TypeError exception: Object doesn't support this property or method" if I try to use custom/prebuilt search object manually,
Q: how people that use GWT toolkit will be able to build application widgets like that one: http://www.google.com/uds/solutions/videobar/index.html (AJAX Video Bar example, no GSearchControl used) with currently provided solution?
Hi, I downloaded the milestone and tried the sample. I like the Google API Library implementation over mapitz's because the syntax are closer to the origional javascript, although I do not know either implementation in depth.
I've been writing some Map API code with javascript. One of my general question is: how do I customize the map api classes with the GWT API? Do I write the code in javascript and then wrap it with JSNI, or can I actually implement the logic in java and the the compiler will export them to some javascript similar to the origional hand written ones? I think this is a common question for a lot of map api users.
In my situation, I have a customized projection class which extends GProjection via prototype and override the necessary functions like fromLatLngToPixel. Now, can I write java code to subclass com.google.gwt.maps.client.geom.Projection (like com.google.gwt.maps.client.geom.MercatorProjection)? or should I just use my origional GLambertConicConformalProjection javascript code and somehow wired via JSNI?
Thanks,
On Sep 7, 11:18 am, "Miguel Méndez" <mmen...@google.com> wrote:
> For the next installment of the Google API Library for > GWT<http://code.google.com/p/gwt-google-apis/>, > we are working to add support for the Google Maps API and the Google AJAX > Search API. This email is to let you know about a milestone build that we've > produced to get your feedback on the API and see how well it works for your > needs. This is not intended to be used for production, there may be breaking > API changes before a true release and please report any bugs over on the issue > tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
Glad to know that the GALGWT libraries have picked your interest :-)
Unfortunately, you won't be able to subclass the classes you're mentioning because some of them are declared as final, preventing inheritance. This was done to make it easy for developers to use the API correctly and to make it hard to use the API incorrectly, although it does carry the consequence of preventing inheritance for developers who might be aware of the full breadth of their changes.
Luckily there is a solution that gives developers this flexibility while still maintaining the API's tight design. What you might find is a better solution is to use composition rather than inheritance. Essentially, you would create your own custom class that would wrap the classes whose functionality you want to extend from the API and use that wrapper class in your application.
Depending on the extent of your customizations, however, it might be better to interact with the original JavaScript code you've already written through JSNI rather than reproduce this functionality in a wrapper class.
> Hi, > I downloaded the milestone and tried the sample. I like the Google API > Library implementation over mapitz's because the syntax are closer to > the origional javascript, although I do not know either implementation > in depth.
> I've been writing some Map API code with javascript. One of my general > question is: how do I customize the map api classes with the GWT API? > Do I write the code in javascript and then wrap it with JSNI, or can I > actually implement the logic in java and the the compiler will export > them to some javascript similar to the origional hand written ones? I > think this is a common question for a lot of map api users.
> In my situation, I have a customized projection class which extends > GProjection via prototype and override the necessary functions like > fromLatLngToPixel. Now, can I write java code to subclass > com.google.gwt.maps.client.geom.Projection (like > com.google.gwt.maps.client.geom.MercatorProjection)? or should I just > use my origional GLambertConicConformalProjection javascript code and > somehow wired via JSNI?
> > For the next installment of the Google API Library for > > GWT<http://code.google.com/p/gwt-google-apis/>, > > we are working to add support for the Google Maps API and the Google > AJAX > > Search API. This email is to let you know about a milestone build that > we've > > produced to get your feedback on the API and see how well it works for > your > > needs. This is not intended to be used for production, there may be > breaking > > API changes before a true release and please report any bugs over on the > issue > > tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
A simple suggestion is to rename all classes same with the javascript class name, e.g. use GLatLng instead of LatLng. Most users who may use this wrapper more or less have used the original js api so same names/ methods/constructor signature will be more comfortable.
On Sep 7, 11:18 am, "Miguel Méndez" <mmen...@google.com> wrote:
> For the next installment of the Google API Library for > GWT<http://code.google.com/p/gwt-google-apis/>, > we are working to add support for the Google Maps API and the Google AJAX > Search API. This email is to let you know about a milestone build that we've > produced to get your feedback on the API and see how well it works for your > needs. This is not intended to be used for production, there may be breaking > API changes before a true release and please report any bugs over on the issue > tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
I would actually prefer the opposite approach: use less shorthand, jargon, and abbreviation. Use clear and concise class and method names which are accessible to Java developers instead of trying to write a Java library for JS developers.
> A simple suggestion is to rename all classes same with the javascript > class name, e.g. use GLatLng instead of LatLng. Most users who may use > this wrapper more or less have used the original js api so same names/ > methods/constructor signature will be more comfortable.
> > For the next installment of the Google API Library for > > GWT<http://code.google.com/p/gwt-google-apis/>, > > we are working to add support for the Google Maps API and the Google AJAX > > Search API. This email is to let you know about a milestone build that we've > > produced to get your feedback on the API and see how well it works for your > > needs. This is not intended to be used for production, there may be breaking > > API changes before a true release and please report any bugs over on the issue > > tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
Thanks for trying out the library and providing feedback! My comments are inline.
On 9/8/07, Peter Blazejewicz <peter.blazejew...@gmail.com> wrote:
> hi Miguel and all Google API Library for GWT Team, > great work, > Even if I played only with AJAX Search API wrapper yesterday and that > was really a pleasure to play with this beta api (I left maps for few > other days to play with them), > I'm already quite experienced with your way of binding JS to Java by > testing Ajax Feed Api project and Gears to some extent so that was > really easy to use new libraries. > Everything works the way I would expect - however I'm just wondering > what are your plans with that api because there is couple of things > that took my attention (again AJAX Search API only): > - it looks api will be designed to strictly UI based use via > GSearchControl widget only
You can use a Searcher directly. So the following code will work:
WebSearch webSearch = new WebSearch(); webSearch.addSearchListener(new SearchListener() { public void onSearchResult(Search search, Result result) { // The results will end up here. Window.alert(result.toString()); }}); webSearch.execute("Foo");
We made a conscious decision to support the use of the GSearchControl and direct use of the searcher objects. However, we avoided the customization of the UI via GSearchForm or output element redirection for now.
- it looks I cannot use GSearch objects directly becase I"m not able
> to bind any results to SearchResultsListener > What is "setSearchCompleteCallbock" you've wrote??? (I know you know > what I'm wrote here). I guess the way putting me off using my custom > UI elements for results because I will always get "JavaScript > TypeError exception: Object doesn't support this property or method" > if I try to use custom/prebuilt search object manually,
> Thank you for the prompt reply. > Actually the class I am trying to subclass is not defined as final, it > is an abstract class which means it is supposed to be subclassed, > right? (package com.google.gwt.maps.client.geom; public abstract class > Projection)
Yes, Projection is intended to be extended. However, MercatorProjection is not. You can look at how MercatorProjection is currently implemented to see how you could do this. Beware that you will want to look issues 28 and 29 before attempting to do this.
I do not really see how composition works in this context.
> If I do inheritance, shoud l do it in GWT like
> public final class LambertConicConformalProjection extends Projection > {. > protected Point convertLatLngToPixel(LatLng latlng, int zoomLevel) { > // do real math plumbing here. > // or > //or wrap the origional javascript? > } > }
> Also, how to wrap a javascript class that derived from a map api > class, not just calling a function?
I don't quite follow the question here. Could you elaborate?
To give you a sense of how my original javascript class look like,
> The core issue is the GLambertConicConformalProjection class. It's > javascript code is actually translated from java/c code, so it will be > nice to directly write those code in java.:)
You should be able to declare a subclass of Projection that is LambertConicConformalProjection and move this into Java code. You should be able to look at the source code in svn to see how we do this.
> On Sep 28, 12:28 pm, "Sumit Chandel" <sumitchan...@google.com> wrote: > > Hi COCGIS,
> > Glad to know that the GALGWT libraries have picked your interest :-)
> > Unfortunately, you won't be able to subclass the classes you're > mentioning > > because some of them are declared as final, preventing inheritance. This > was > > done to make it easy for developers to use the API correctly and to make > it > > hard to use the API incorrectly, although it does carry the consequence > of > > preventing inheritance for developers who might be aware of the full > breadth > > of their changes.
> > Luckily there is a solution that gives developers this flexibility while > > still maintaining the API's tight design. What you might find is a > better > > solution is to use composition rather than inheritance. Essentially, you > > would create your own custom class that would wrap the classes whose > > functionality you want to extend from the API and use that wrapper class > in > > your application.
> > Depending on the extent of your customizations, however, it might be > better > > to interact with the original JavaScript code you've already written > through > > JSNI rather than reproduce this functionality in a wrapper class.
> > > Hi, > > > I downloaded the milestone and tried the sample. I like the Google API > > > Library implementation over mapitz's because the syntax are closer to > > > the origional javascript, although I do not know either implementation > > > in depth.
> > > I've been writing some Map API code with javascript. One of my general > > > question is: how do I customize the map api classes with the GWT API? > > > Do I write the code in javascript and then wrap it with JSNI, or can I > > > actually implement the logic in java and the the compiler will export > > > them to some javascript similar to the origional hand written ones? I > > > think this is a common question for a lot of map api users.
> > > In my situation, I have a customized projection class which extends > > > GProjection via prototype and override the necessary functions like > > > fromLatLngToPixel. Now, can I write java code to subclass > > > com.google.gwt.maps.client.geom.Projection (like > > > com.google.gwt.maps.client.geom.MercatorProjection)? or should I just > > > use my origional GLambertConicConformalProjection javascript code and > > > somehow wired via JSNI?
> > > > For the next installment of the Google API Library for > > > > GWT<http://code.google.com/p/gwt-google-apis/>, > > > > we are working to add support for the Google Maps API and the Google > > > AJAX > > > > Search API. This email is to let you know about a milestone build > that > > > we've > > > > produced to get your feedback on the API and see how well it works > for > > > your > > > > needs. This is not intended to be used for production, there may be > > > breaking > > > > API changes before a true release and please report any bugs over on > the > > > issue > > > > tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
When we started out, I argued for dropping the G prefix and adhering to more Java-friendly names where possible. I still think that this is the right decision, although I appreciate where COCGIS is coming from.
I should also point out that with things like the AJAX API Loader, the names will be changed anyway to drop the G prefix, etc. Check out AJAX API Loader: Namespaces<http://code.google.com/apis/ajax/documentation/#Namespaces>for more information.
On 10/2/07, Isaac Truett <itru...@gmail.com> wrote:
> I would actually prefer the opposite approach: use less shorthand, > jargon, and abbreviation. Use clear and concise class and method names > which are accessible to Java developers instead of trying to write a > Java library for JS developers.
> > A simple suggestion is to rename all classes same with the javascript > > class name, e.g. use GLatLng instead of LatLng. Most users who may use > > this wrapper more or less have used the original js api so same names/ > > methods/constructor signature will be more comfortable.
> > On Sep 7, 11:18 am, "Miguel M ndez" <mmen...@google.com> wrote: > > > Hey folks,
> > > For the next installment of the Google API Library for > > > GWT<http://code.google.com/p/gwt-google-apis/>, > > > we are working to add support for the Google Maps API and the Google > AJAX > > > Search API. This email is to let you know about a milestone build that > we've > > > produced to get your feedback on the API and see how well it works for > your > > > needs. This is not intended to be used for production, there may be > breaking > > > API changes before a true release and please report any bugs over on > the issue > > > tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
hello Miguel, thanks for comments, I see that after fix for typo in underlying callback we will be able to use custom seach listeners now, regards, Peter
On Oct 2, 4:42 pm, "Miguel Méndez" <mmen...@google.com> wrote:
> Thanks for trying out the library and providing feedback! My comments are > inline.
> On 9/8/07, Peter Blazejewicz <peter.blazejew...@gmail.com> wrote:
> > hi Miguel and all Google API Library for GWT Team, > > great work, > > Even if I played only with AJAX Search API wrapper yesterday and that > > was really a pleasure to play with this beta api (I left maps for few > > other days to play with them), > > I'm already quite experienced with your way of binding JS to Java by > > testing Ajax Feed Api project and Gears to some extent so that was > > really easy to use new libraries. > > Everything works the way I would expect - however I'm just wondering > > what are your plans with that api because there is couple of things > > that took my attention (again AJAX Search API only): > > - it looks api will be designed to strictly UI based use via > > GSearchControl widget only
> You can use a Searcher directly. So the following code will work:
> WebSearch webSearch = new WebSearch(); > webSearch.addSearchListener(new SearchListener() { > public void onSearchResult(Search search, Result result) { > // The results will end up here. > Window.alert(result.toString()); > }}); > webSearch.execute("Foo");
> We made a conscious decision to support the use of the GSearchControl and > direct use of the searcher objects. However, we avoided the customization > of the UI via GSearchForm or output element redirection for now.
> - it looks I cannot use GSearch objects directly becase I"m not able
> > to bind any results to SearchResultsListener > > What is "setSearchCompleteCallbock" you've wrote??? (I know you know > > what I'm wrote here). I guess the way putting me off using my custom > > UI elements for results because I will always get "JavaScript > > TypeError exception: Object doesn't support this property or method" > > if I try to use custom/prebuilt search object manually,
final MapWidget map= new MapWidget(new LatLng(35.249208, -80.843099), 10); map.setSize("500px", "500px"); CopyrightCollection myCopyright=new CopyrightCollection(""); myCopyright.addCopyright(new Copyright(1,new LatLngBounds(new LatLng(34,-81),new LatLng(36,-79)),10,"")); TileLayer tileLayer = new TileLayer(myCopyright,10,18){ public boolean isPng(){return true;} public double getOpacity(){return 1.0;} public String getTileURL(Point tile, int zoomLevel){ return "http://www.google.com/apis/maps/documentation/ examples/include/tile_crosshairs.png"; } }; //TileLayerOverlay layerOverlay=new TileLayerOverlay(tileLayer); //map.addOverlay(layerOverlay); MapType mapType=new MapType(new TileLayer[]{tileLayer},new MercatorProjection(20),"MyMap"); map.addMapType(mapType); map.addControl(new MapTypeControl()); RootPanel.get().add(map);//
}
The tile layer works fine as a tile overlay on top of normal maps, however, when I click the "MyMap" type, I got the following error: com.google.gwt.dev.shell.HostedModeException: Calling method 'createPeer': JS object of type number, expected com.google.gwt.core.client.JavaScriptObject at com.google.gwt.dev.shell.JsValueGlue.get(JsValueGlue.java:114) at com.google.gwt.dev.shell.ie.SwtOleGlue.convertVariantsToObjects(SwtOleGlue. java: 57) at com.google.gwt.dev.shell.ie.IDispatchImpl.callMethod(IDispatchImpl.java: 119) at com.google.gwt.dev.shell.ie.IDispatchProxy.invoke(IDispatchProxy.java: 150)
If I can not get MapType working in the default Mercator projection, custom Projection won't work at all, regardless it is implemented in java or js+jsni.
Any thoughts?
(BWT, I did notice the getTileUrl in js api changed to getTileURL in gwt, assuming it is a naming convention for gwt?)
Thanks!
On Oct 2, 10:55 am, "Miguel Méndez" <mmen...@google.com> wrote:
> > Thank you for the prompt reply. > > Actually the class I am trying to subclass is not defined as final, it > > is an abstract class which means it is supposed to be subclassed, > > right? (package com.google.gwt.maps.client.geom; public abstract class > > Projection)
> Yes, Projection is intended to be extended. However, MercatorProjection is > not. You can look at how MercatorProjection is currently implemented to see > how you could do this. Beware that you will want to look issues 28 and 29 > before attempting to do this.
> I do not really see how composition works in this context.
> > If I do inheritance, shoud l do it in GWT like
> > public final class LambertConicConformalProjection extends Projection > > {. > > protected Point convertLatLngToPixel(LatLng latlng, int zoomLevel) { > > // do real math plumbing here. > > // or > > //or wrap the origional javascript? > > } > > }
> > Also, how to wrap a javascript class that derived from a map api > > class, not just calling a function?
> I don't quite follow the question here. Could you elaborate?
> To give you a sense of how my original javascript class look like,
> > The core issue is the GLambertConicConformalProjection class. It's > > javascript code is actually translated from java/c code, so it will be > > nice to directly write those code in java.:)
> You should be able to declare a subclass of Projection that is > LambertConicConformalProjection and move this into Java code. You should be > able to look at the source code in svn to see how we do this.
> Thanks!
> > On Sep 28, 12:28 pm, "Sumit Chandel" <sumitchan...@google.com> wrote: > > > Hi COCGIS,
> > > Glad to know that the GALGWT libraries have picked your interest :-)
> > > Unfortunately, you won't be able to subclass the classes you're > > mentioning > > > because some of them are declared as final, preventing inheritance. This > > was > > > done to make it easy for developers to use the API correctly and to make > > it > > > hard to use the API incorrectly, although it does carry the consequence > > of > > > preventing inheritance for developers who might be aware of the full > > breadth > > > of their changes.
> > > Luckily there is a solution that gives developers this flexibility while > > > still maintaining the API's tight design. What you might find is a > > better > > > solution is to use composition rather than inheritance. Essentially, you > > > would create your own custom class that would wrap the classes whose > > > functionality you want to extend from the API and use that wrapper class > > in > > > your application.
> > > Depending on the extent of your customizations, however, it might be > > better > > > to interact with the original JavaScript code you've already written > > through > > > JSNI rather than reproduce this functionality in a wrapper class.
> > > Hope that helps, > > > -Sumit Chandel
> > > On 9/28/07, COCGIS <coc...@gmail.com> wrote:
> > > > Hi, > > > > I downloaded the milestone and tried the sample. I like the Google API > > > > Library implementation over mapitz's because the syntax are closer to > > > > the origional javascript, although I do not know either implementation > > > > in depth.
> > > > I've been writing some Map API code with javascript. One of my general > > > > question is: how do I customize the map api classes with the GWT API? > > > > Do I write the code in javascript and then wrap it with JSNI, or can I > > > > actually implement the logic in java and the the compiler will export > > > > them to some javascript similar to the origional hand written ones? I > > > > think this is a common question for a lot of map api users.
> > > > In my situation, I have a customized projection class which extends > > > > GProjection via prototype and override the necessary functions like > > > > fromLatLngToPixel. Now, can I write java code to subclass > > > > com.google.gwt.maps.client.geom.Projection (like > > > > com.google.gwt.maps.client.geom.MercatorProjection)? or should I just > > > > use my origional GLambertConicConformalProjection javascript code and > > > > somehow wired via JSNI?
> > > > > For the next installment of the Google API Library for > > > > > GWT<http://code.google.com/p/gwt-google-apis/>, > > > > > we are working to add support for the Google Maps API and the Google > > > > AJAX > > > > > Search API. This email is to let you know about a milestone build > > that > > > > we've > > > > > produced to get your feedback on the API and see how well it works > > for > > > > your > > > > > needs. This is not intended to be used for production, there may be > > > > breaking > > > > > API changes before a true release and please report any bugs over on > > the > > > > issue > > > > > tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
I looked the map type error a little more(see an earlier post), it seems the problem is inside the GMercatorProjection and Projection class.
1. The Projection.tileCheckRange method's signature changed from the js API, and I don't think it is because of naming convention as in the case of getTileURL. The last parameter tilesize is com.google.gwt.maps.client.geom.Size instead of int. However, in the runtime, what's been passed in by the js API is actually a number (256), causing the errors. (Calling method 'createPeer': JS object of type number, expected com.google.gwt.core.client.JavaScriptObject).
2. In the js API, a typical use of GProjection class is call method fromLatLngToPixel etc in overlay or control class to position stuff on top the map, but com.google.gwt.maps.client.geom.MercatorProjection has those two method as protected, so you can not really have some code like:
Projection prj=new MercatorProjection(20); Point p=prj.fromLatLngToPixel(new LatLng(40, -80));
which is supposed to be a "correct" use. Any special reason why those methods are protected? They are meant to be called.
> > Thank you for the prompt reply. > > Actually the class I am trying to subclass is not defined as final, it > > is an abstract class which means it is supposed to be subclassed, > > right? (package com.google.gwt.maps.client.geom; public abstract class > > Projection)
> Yes, Projection is intended to be extended. However, MercatorProjection is > not. You can look at how MercatorProjection is currently implemented to see > how you could do this. Beware that you will want to look issues 28 and 29 > before attempting to do this.
> I do not really see how composition works in this context.
> > If I do inheritance, shoud l do it in GWT like
> > public final class LambertConicConformalProjection extends Projection > > {. > > protected Point convertLatLngToPixel(LatLng latlng, int zoomLevel) { > > // do real math plumbing here. > > // or > > //or wrap the origional javascript? > > } > > }
> > Also, how to wrap a javascript class that derived from a map api > > class, not just calling a function?
> I don't quite follow the question here. Could you elaborate?
> To give you a sense of how my original javascript class look like,
> > The core issue is the GLambertConicConformalProjection class. It's > > javascript code is actually translated from java/c code, so it will be > > nice to directly write those code in java.:)
> You should be able to declare a subclass of Projection that is > LambertConicConformalProjection and move this into Java code. You should be > able to look at the source code in svn to see how we do this.
> Thanks!
> > On Sep 28, 12:28 pm, "Sumit Chandel" <sumitchan...@google.com> wrote: > > > Hi COCGIS,
> > > Glad to know that the GALGWT libraries have picked your interest :-)
> > > Unfortunately, you won't be able to subclass the classes you're > > mentioning > > > because some of them are declared as final, preventing inheritance. This > > was > > > done to make it easy for developers to use the API correctly and to make > > it > > > hard to use the API incorrectly, although it does carry the consequence > > of > > > preventing inheritance for developers who might be aware of the full > > breadth > > > of their changes.
> > > Luckily there is a solution that gives developers this flexibility while > > > still maintaining the API's tight design. What you might find is a > > better > > > solution is to use composition rather than inheritance. Essentially, you > > > would create your own custom class that would wrap the classes whose > > > functionality you want to extend from the API and use that wrapper class > > in > > > your application.
> > > Depending on the extent of your customizations, however, it might be > > better > > > to interact with the original JavaScript code you've already written > > through > > > JSNI rather than reproduce this functionality in a wrapper class.
> > > Hope that helps, > > > -Sumit Chandel
> > > On 9/28/07, COCGIS <coc...@gmail.com> wrote:
> > > > Hi, > > > > I downloaded the milestone and tried the sample. I like the Google API > > > > Library implementation over mapitz's because the syntax are closer to > > > > the origional javascript, although I do not know either implementation > > > > in depth.
> > > > I've been writing some Map API code with javascript. One of my general > > > > question is: how do I customize the map api classes with the GWT API? > > > > Do I write the code in javascript and then wrap it with JSNI, or can I > > > > actually implement the logic in java and the the compiler will export > > > > them to some javascript similar to the origional hand written ones? I > > > > think this is a common question for a lot of map api users.
> > > > In my situation, I have a customized projection class which extends > > > > GProjection via prototype and override the necessary functions like > > > > fromLatLngToPixel. Now, can I write java code to subclass > > > > com.google.gwt.maps.client.geom.Projection (like > > > > com.google.gwt.maps.client.geom.MercatorProjection)? or should I just > > > > use my origional GLambertConicConformalProjection javascript code and > > > > somehow wired via JSNI?
> > > > > For the next installment of the Google API Library for > > > > > GWT<http://code.google.com/p/gwt-google-apis/>, > > > > > we are working to add support for the Google Maps API and the Google > > > > AJAX > > > > > Search API. This email is to let you know about a milestone build > > that > > > > we've > > > > > produced to get your feedback on the API and see how well it works > > for > > > > your > > > > > needs. This is not intended to be used for production, there may be > > > > breaking > > > > > API changes before a true release and please report any bugs over on > > the > > > > issue > > > > > tracker <http://code.google.com/p/gwt-google-apis/issues/list>.
If any other newbies are trying to add this to their application, you might benefit from knowing this:
1. Add the jar to your classpath in your eclipse project and/or add it to the classpath in the MyProject-shell.cmd
2. Add an "inherits" tag to src/com/mydomain/MyProject.gwt.xml: <module>
<!-- Inherit the core Web Toolkit stuff. --> <inherits name='com.google.gwt.user.User'/>
<!-- ******************** --> <!-- Add this line here --> <!-- ******************** --> <inherits name='com.google.gwt.maps.GoogleMaps'/>
<!-- Specify the app entry point class. --> <entry-point class='com.mydomain.client.MyProject'/>
</module>
3. Add a reference to the google maps API javascript to your html file _before_ the reference to your own project's generated javascript (note also: replace YourKey with your google maps key):
