kengu / gwt-leaflet Goto Github PK
View Code? Open in Web Editor NEWGWT library for Leaflet
License: Other
GWT library for Leaflet
License: Other
In which license is distributed ?
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
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.
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.
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
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:
JSObject
and friends to latest gwt-openlayers versionJSObject
and friends to org.discotools.gwt.util.client
in gwt-utilAttributes
, ElementHelper
and data type wrappers.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 :
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.
Latest GWT version is now 2.5. Move to this version.
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.
It makes no sense having both. Combine them.
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
.
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.
All *Options
implementations should be located with the class which use it.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.