This will detect any API changes in Leaflet.js and regression errors. The tests are limited to detecting regression errors due changes in Leaflet API only. Tests of gwt-leaflet specific API will come later.

Hi and thanks for the great project.

When looking at the code, i can see that there is a lot of work, replicating the JS structure of Leaflet into Java classes with this JNI binding to JavaScript code.
It looks like a giant ammount of work

I'm very new to GWT (actually want to use Vaadin which relies on GWT) and I wanted to know if all this code was generated by hand or if there was some kind of tool that would "convert" the JS code into all these wrappers?

Also in the example (http://gwtl-example.appspot.com/example.html), i can see that the file leaflet-src.js is still loaded in the page. What is the point of having the original library and pieces of that code in the JSNI comments?

Sorry if that's a noob question :)

Fabien

In which license is distributed ?

I'm almost ready to move gwt-leaflet to DISCOTools (see #14).

As preparation for this, most of gwt-leaflet parent pom is moved to gwt-dt. The change in gwt-leaflet is limited to removing most of the content in gwt-leaflet parent pom and change parent to org.discotools.gwt:gwt-dt.

I've sent a request for maven repository hosting to Sonatype, which is now granted.

Issue #4 updated maven groupid and java/gwt namespace to org.discotools.gwt.leaflet.
Next step is to move ownership of gwt-leaflet to DISCOTools.

I will use "the github way", following this procedure.

Note: Any followers that want to track the new remote instead of this soon-to-be personal clone,
have to run the following command locally:

git remote set-url origin https://github.com/DISCOTools/gwt-leaflet.git

Reference

Changing a remote's URL

Hi Kenneth,
I've take some times to look at your devel branch, which looks like the one I was thinking.

Nevertheless, by implementing Marker, I've get into trouble, specially when I tried to integrate it into the example.java.

So, I started to look around and quickly gave a eye on the gwt-openlayer sources codes. What I can say is that the inheritance process they use is a good practive that you should consider, specially the JSObject they embedded into a superclass. This object can be use in the implementation class.

In your gwt wrapping, you're always define an interface, then you create an implementation of the class, and finally, you define a new method to create the object itself in a kind of factory class. This process could be shorter by using the openlayer strategy.

From my part, I tried the following to implement the marker :

// Create a new LatLng class which extend the JSObjectWrapper :
public class LLatLng extends JSObjectWrapper {

protected LLatLng(JSObject element) {
    super(element);
}

public LLatLng(double lon, double lat) {
    this (LLatLngImpl.create(lon, lat));
}

public double lon() {
    return LLatLngImpl.lon(getJSObject());
}

public double lat() {
    return LLatLngImpl.lat(getJSObject());
}

}

// Then define the implementation :
class LLatLngImpl {

public static native JSObject create(double lat, double lon)/*-{
    return new $wnd.L.LatLng(lat, lon);
}-*/;

public static native double lon(JSObject self)/*-{
    return self.lon;
}-*/;

public static native double lat(JSObject self)/*-{
    return self.lat;
}-*/;

}

After that, I create the marker :
public class Marker extends JSObjectWrapper {

protected Marker(JSObject element) {
    super(element);
}

public Marker(LLatLng latlng) {
    this (MarkerImpl.create(latlng.getJSObject()));
}

public void addTo(String mapname) {
    MarkerImpl.addTo(getJSObject(), mapname);
}

@SuppressWarnings("serial")
public final static Options DEFAULT = new Options(true){
    @Override
    protected void fill() {
        // TODO: Add required options (one at this point)
    }
};

Finally create the implementation of the marker :
/**

• {@link Marker} implementation.

• @author Lionel Leiva
  *
  */
  public class MarkerImpl {

  public static native JSObject create(JSObject latlng, JSObject options)/-{
  return new $wnd.L.Marker(latlng,options);
  }-/;

  public static native JSObject create(JSObject latlng)/-{
  return new $wnd.L.Marker(latlng);
  }-/;

  public static native JSObject addTo(JSObject self, String mapname)/-{
  var map = $wnd.gwtl.maps[mapname];
  return self.addTo(map);
  }-/;

}

// In the example.java, i call them as follow :
....
// Create map center position
LatLng center = L.type().latlng(59.915, 10.754);
LLatLng latlng = new LLatLng(59.915, 10.754);
Marker marker = new Marker(latlng);
marker.addTo("map");

Notice that I make a shortcut by calling the name of the widget map, because for this example, I didn't want to redefine the map class with the inheritance strategy.

I really think that using the JSObject will improve your code, because making easier the conversion into jsni.
What do you think about it?

Have a good day

Lionel

It makes no sense having both. Combine them.

All *Options implementations should be located with the class which use it.

I think is is better to locate option implementations with the class which accepts it. Aka SearchControlOptions should be moved from org.gwt.leaflet.client.options to org.gwt.leaflet.client.controls.search. When moved, a better name for it would be SearchOptions, which is much shorter.

I see that we need to add some version validation support for JSNI wrapper methods. This also involves allowing the user to choose which version of wrapped 3rd-party js-script should be loaded by GWT.

I see two options,

*Add multiple .gwt.xml module definitions, each specifying a different 3rd-party version.

This is easy to implement. For example leaflet version 0.4.5 becomes *.Core_045.gwt.xml. This approach could also be adapted to user-specified leaflet library where the path is hard-coded to a location which the user has access to, for example *.Core_custom.gwt.xml includes .../WEB-INF/lib/leaflet/custom/leaflet.js.

Add method for support for user-specified version

This is more flexible, but have serveral issues which makes the code more complex. First of all, any version-to-js mapping must be specified such that the 3rd-party library is loaded BEFORE any GWT entry-point is loaded. GWT solves this for us when scripts tags are specified in the *.gwt.xml file. There are solutions to this problem, but it involves callbacks which make the code less readable. I have some ideas on how to overcome this problem.

I think the last options is the best. I will look into it and report back.

Latest GWT version is now 2.5. Move to this version.

I'ts time for some restructuring and refactoring before first official release. This one should not affect the API, so no breakage is expected. But, anyone using JSObject in project dependent on gwt-leaflet, will break.

These are the changes:

1. Update JSObject and friends to latest gwt-openlayers version
2. Move JSObject and friends to org.discotools.gwt.util.client in gwt-util
3. Add missing utility classes - Attributes, ElementHelper and data type wrappers.

Hi

I'm just about ready to make the first official release. Snapshots are now deployed to Sonatype snapshot repository on every push to origin (working on limiting deployment to origin/master only, but Travis contains a bug preventing this). Next step is to stage and promote Maven artifacts for release.

Do you (@leiva and @igieon) have any thing in the pipeline that you want to include in this release?

I plan to complete milestone v0.3 within a week or so.

Hi Kengu,
I've started to use your Leaflet wrapping in gwt, and it looks like promising. Thanks for your good job.
However, as I try to integrate your code in another SmartGwt application, I need some further addons. By the way, don't you think that it won't be easier for external developper (as me) to organize your library as Leaflet does.

For instance, the different objects of the library should be organize as follow :

API

• UI
  
  • Marker (work in progress)
    
  • Popup (work in progress)
    
• Rasters
  
  • TileLayer
    
  • WMSLayer
    
• +Vector Layers
  
  • Path
    
  • Polyline
    
  • MultiPolyline
    
  • Polygon
    
  • MultiPolygon
    
  • Rectangle
    
  • Circle
    
  • CircleMarker
    
• Other Layers
  
  • LayerGroup (work in progress)
    
• etc ....
  

Last point, I suggest to upgrade to the last version of Leaflet (0.4.4) to stay as closest as possible to the original.

Cheers

Lionel Leiva

I have sent a request for maven repository hosting to Sonatype. This requires that the groupid starts with a domain which is owned by me or an organisation (see choosing your coordinates), or reflects the project hosting, aka com.github.kengu. Since I prefer the former, I have decided to refactor gwt-leaflet namespace and groupid to org.discotools.gwt. DISCOTools is a community driven project, which exists at Github as an organisation.