Thanks Jen,
On Sunday, June 5, 2016 at 5:41:05 AM UTC-7, Jens wrote:
-- Let me try to explain the issue better:
In your example, JsArray must have a bunch of native methods mapped to the native JavaScript Array API. None of these methods bring much value to the Java developer, who for years have been very happy with the Java native Collection,List,Map interfaces, and now enjoys the Java 8 additions.
All we need is the JsInterop to map an List (or Java array) from the Java world into plain array in the JavaScript world. Transparently. (or with the help of minor annotation or two). The same is needed for maps.
Without such transparent mapping, you are faced with some unpleasant choices:
1. You write converters and adapters as you showed in your asCollection()example. That is not going to help you if you decide to re-use your Something class on the server (e.g. on the JVM) side, as it is still cannot exist there due to the reference to JsArray. You will have to duplicate it with something like JavaSomething that has a reference to List<Person>.
2. You try something like what Paul did: define an umbrella Array interface that strictly implements and the native JavaScript Array API (plus some extra overlay methods) and then duplicate this in the Java world with Java-only mirror class like this (kudos to Paul, btw, for putting his code out there!). Then you could potentially re-use your Something class in both the JS and Java world, if it reference the umbrella Array interface instead. But now you force Java developers to learn and deal with the JavaScript array API, when they are perfectly happy with java.util.List/Collection ! This will lead to more converters in your code, for sure ...My experience over the years is that such clever tricks lead to even more kludge down the road. For example, In the old EJB 2.x model abused interfaces (remember the Home or Entity Bean interfaces? Or the Remote and Local ones ... Jeez ) until all this was wiped out and simplified with transparent frameworks such as JPA, JAX-B and Jackson to remove the kludge.
My hope is that JsInterop evolves towards transparent collections mapping, so GWT developers do not have to write or depend on plumbing code, at least not for common collections .
Btw, thank you and Paul for sharing your code and discussing JsInterop, as for GWT JsInterop projects, given the current state, your example code is the only way possible!
Cheers
On Sunday, June 5, 2016 at 5:41:05 AM UTC-7, Jens wrote:
When you think about it, other Java APIs (jaxb, jpa, Jackson) do go the extra mile to accommodate Java collectionsWell kind of bad comparison right? These Java APIs either serialize/deserialize based on a defined principle or stay in Java land anyways., and the example above looks like can be exported to js object (could use a helper annotation @JsX or two).You don't "export" Java to JS but instead you consume JS using Java. That means you would need to have a class that implements the Map interface and takes a JS map as constructor parameter. Then you can implement the Java API on top of the JavaScript API. In some cases you can simply delegate to the JS API, in some cases you can't.But thats something JsInterop does not do, however nobody stops you from having something like
@JsType(native = true)
class JsArray<T> {
// ...get / set / shift / slice / etc...
@JsOverlay
Collection<T> asCollection() {
// Java API on top of JS API
return new JsArrayCollectionAdapter<>(this );
}
@JsOverlay
List<T> asList() {
// Java API on top of JS API
return new JsArrayListAdapter<>(this);
}
}
@JsType(native = true)
class Something {
@JsProperty
JsArray<Person> persons;
@JsOverlay
List<Person> getPersons() {
return persons.asList();
}
@JsOverlay
void setPersons(List<Person> newPersons) {
// might use ES6 Array.from(newPersons.toArray()) if possible, otherwise fallback to manual copying
persons = JsUtils.asJsArray(newPersons);
// alternatively do it through the adapter
List<Person> adapter = persons.asList();
adapter.clear();
adapter.addAll(newPersons);
}
}-- J.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment