Paul,
2. Java developers are not forced to deal with JS Array API on the Java side (JS Array APIs largely redundant from java developer's point of view)
-- Yes, it boils down to JSInterop automatically handling some well-known implementations of java.util.List (LinkedList,ArrayList) as JS arrays. The direction Java->JS is easy: the JsInterop will map anything implementing java.util.List into js array. JS developers only see arrays on the other side, have no idea what the Java developer used. For the opposite direction, if the targeted member is non-standard or ambiguous, a helper converter annotation might be needed, for example:
This may need a helper converter:
@JsType(isNative = true ...)
public class Foo {
...
@JsPropery(useListMapper=com.my.SpecialListConvertor.class)
public List<WhateverJSType> myAmbiguousList;
}
but this should need no helper:
@JsType(isNative = true ...)
public class Foo {
...
@JsPropery
public ArrayList<WhateverJSType> myWellKnownListThatJsInteropKnowHowToHandleAlready;
}
Essentially, this is a converter similar to what Jen put in his example, but made available to JsInterop during code generation.
I still think this approach would be superior that the umbrella interface like your (for example gwt.interop.utils.shared.collections.Array) for 2 reasons:
1. Less code, simpler
Creating instances does not need to be done with dependency injection engine (or worse - global singleton constructor factories, like you did with your latest update. Think carefully about all the cruft this adds!)
2. Java developers are not forced to deal with JS Array API on the Java side (JS Array APIs largely redundant from java developer's point of view)
I have not thought through all the details, but do see the pain if nothing is done ... Just my 2 cents
On Thursday, June 9, 2016 at 6:26:28 AM UTC-7, Paul Stockley wrote:
As Thomas says, it will be impossible to support passing any of the collection interfaces directly through to JS code. You might think however, that you could change the implementation of ArrayList to actually be a JS Array. I don't think this is possible either because an instance of ArrayList needs to fulfill the Java contract of being able to know which interfaces it implements. This is done by having special meta data attached to the object prototype. The minute you start touching the Array prototype you have the potential of incompatibility with existing JS code.Having said that, it is totally possible to implement an adapter to make a JS array look like a List. Below is a very hacky way to do it (the example uses the Array JsNative interface I defined but you could do the same with JsArray)native <E> List<E> asList(Array<E> a) /*-{ l = @java.util.ArrayList::new()() l.@java.util.ArrayList::array = a; return l; }-*/;Array<String> jsArray = Array.create();
jsArray.push("val1"); jsArray.push("val2");
List lArray = asList(jsArray);
//Any changes to lArray will reflect in jsArray and vice versa
lArray.add("val3"); jsArray.push("val4");
I strongly do not recommend using the above approach. A better way would be to create an adapter class that takes the native Array to wrap in the constructor and implements the List methods. I have implemented this in my library.
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