Thomas, In your reply above you were asking if i shouldn't instead
have:
public final native String getAddress() /*-{ return this.address; }-Not really because the GData JS library uses getters/setters (which is nice) so the getAddress method exists on the JS side: http://code.google.com/apis/gdata/jsdoc/1.8/google/gdata/Im.html#getAddress I wasn't aware that "return" wasn't necessary (though it makes sense), this is why i ask stuff. On constants vs enumerations, ok if constants are good enough for the Java GData library then they're good enough for me - it saves me the work of trying to plug the enumeration types into the method parameters and return values. I'm going to follow the same approach as in the following link that you provided: http://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/ltgt/gwt/air/core/client/events/Event.java AsyncCallback seems like a good fit, i counted three classes in the JS GData library (out of 238) that use callbacks: http://code.google.com/apis/gdata/jsdoc/1.8/google/gdata/Feed.html http://code.google.com/apis/gdata/jsdoc/1.8/google/accounts/user.html http://code.google.com/apis/gdata/jsdoc/1.8/google/gdata/Entry.html The Feed and Entry classes always have a pair of callbacks for success and failure, the User class uses single onSuccess callbacks - the onFailure method of the AsyncCallback would never be called, not a major issue, i'm going to assume that the JS method never fails (else it would have an error handler). I'm not entirely sure yet how to implement this with AsyncCallback. For example, for the getSelf method of google.gdata.Entry (http:// code.google.com/apis/gdata/jsdoc/1.8/google/gdata/Entry.html#getSelf) i could do the following: JS function getSelf(<function(Object)> continuation, <function(Error)> opt_errorHandler) Java public final native Entry getSelf(<function(Object)> continuation, <function(Error)> opt_errorHandler)/*-{ //it gets difficult here var cbw1 = { cb: continuation, call: function(o) { @this.cb.AsyncCallback::onSuccess(Ljava/lang/Object;)(o); } } var cbw2 = { cb: opt_errorHandler, call: function(e) { @this.cb.AsyncCallback::onFailure(Lcustom/gdata/aux/FailureError;) (e); } } return this.getSelf(cbw1.call, cbw2.call); }-*/ One unknown here on my part is the JNI notation for generics (http:// java.sun.com/j2se/1.4.2/docs/guide/jni/spec/types.html#wp16432), i'm assuming that it's no different than non-generics and that we still use "L fully-qualified-class ;". Also in my JSNI code above for getSelf, i see that it would fail if the original GData JS Entry.getSelf implementation does the following: Entry.prototype.getSelf = function(continuation, opt_errorHandler){ this.success_cb = continuation; this.failure_cb = opt_errorHandler; //do something } Because then then the "cb" property that the "call" method references won't be available. Maybe there's some neat JS trick that i can use to prevent this but i don't know what it is, unless i store the success and failure callbacks in global vars (which doesn't excite me). Bobby On Apr 19, 8:26 pm, Thomas Broyer <t.bro...@gmail.com> wrote: > On 20 avr, 01:47, Bobby <bobbysoa...@gmail.com> wrote: > > > > > While i have your attention, on #5 and constants Vs enumerations - I > > won't know the value of the constants at the time of generating the > > wrapper (i think that even if i did i would still rather not have them > > hard coded in the wrapper class). This means that i can't have JS > > constants become static final fields in the Java class. I guess in the > > worst case i could have a single JSNI method for retrieving the value > > of a given constant, given the name, or one JSNI method per constant, > > but Enums would be much more developer friendly. > > There has been some news recently about enums in > GWT:http://code.google.com/p/google-web-toolkit/wiki/EnumOptimizationshttp://timepedia.blogspot.com/2009/04/gwts-type-system-is-more-powerf... > > > Just to put things into context, here's a class that defines some > > constants:http://code.google.com/apis/gdata/jsdoc/1.8/google/gdata/Im.html > > > Right now, using enums, this is the GWT wrapper that the generator > > would yield: > > > [code] > > package google.gdata; > > public class Im extends com.google.gwt.core.client.JavaScriptObject { > > public final native String getAddress() /*-{ return this.getAddress > > (); }-*/; > > Er, shouldn't it instead be: > public final native String getAddress() /*-{ return this.address; }- > */; > > > public final native String getLabel() /*-{ return this.getLabel(); > > }- > > */; > > public final native boolean getPrimary() /*-{ return this.getPrimary > > (); }-*/; > > public final native String getProtocol() /*-{ return > > this.getProtocol > > (); }-*/; > > public final native String getRel() /*-{ return this.getRel(); }-*/; > > public final native void setAddress(String address) /*-{ return > > this.setAddress(address); }-*/; > > This "return" is not necessary. > > > > > > > public final native void setLabel(String label) /*-{ return > > this.setLabel(label); }-*/; > > public final native void setPrimary(boolean primary) /*-{ return > > this.setPrimary(primary); }-*/; > > public final native void setProtocol(String protocol) /*-{ return > > this.setProtocol(protocol); }-*/; > > public final native void setRel(String rel) /*-{ return this.setRel > > (rel); }-*/; > > > public static enum Constants { > > PROTOCOL_AIM ("PROTOCOL_AIM"), > > PROTOCOL_GOOGLE_TALK ("PROTOCOL_GOOGLE_TALK"), > > PROTOCOL_ICQ ("PROTOCOL_ICQ"), > > PROTOCOL_JABBER ("PROTOCOL_JABBER"), > > PROTOCOL_MSN ("PROTOCOL_MSN"), > > PROTOCOL_QQ ("PROTOCOL_QQ"), > > PROTOCOL_SKYPE ("PROTOCOL_SKYPE"), > > PROTOCOL_YAHOO ("PROTOCOL_YAHOO"), > > REL_HOME ("REL_HOME"), > > REL_OTHER ("REL_OTHER"), > > REL_WORK ("REL_WORK"); > > private final String name; > > Constants(String name) { > > this.name = name; > > } > > public String value(){ return getConstantValue(this.name); } > > If the enum's "value" is the same, I'd rather not use this private > field, and instead use name(): > public String value() { return getConstantValue(this.name()); } > > You could also probably initialize a static map (or at least keep a > reference to the google.gdata.Im object) for slight better perfs: > > private static final jso; > > static { > jso = initJso();} > > private static native JavaScriptObject initJso() /*-{ return > google.gdata.Im; }-*/; > > private static native String getConstantValue(JavaScriptObject map, > String name) /*-{ > return map[name]; > > }-*/; > > So the class would have an inner enumeration that retrieves the values > > via JSNI. Right now i have now idea if this works because i don't know > > how GWT handles enums, let alone inner enums in an overlay type. > > I'm almost sure it would work. > > In this particlar case, I wouldn't use an enum though, as these > constants are only "sample values" (common values). And I would use > "true Java constants" too. > (FYI, the GData Java Client use constants for > these:http://code.google.com/intl/fr-FR/apis/gdata/javadoc/com/google/gdata... > ) > > An example using an > enum:http://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/l...http://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/l... > > An example using "just > constants":http://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/l... > > > For #6 and Callbacks, i agree that interfaces are much more developer > > friendly, but these would be difficult to dynamically generate (for > > example, what would the generator name the interface, whould it reuse > > interfaces across different methods?). > > After a quick scan of the GData Java client API, there doesn't seem to > be much callbacks, so in the JS API most if not all callbacks should > be due to its async nature, thus are likely to be a pair of (<function > (Object)> continuation, <function(Error)> opt_errorHandler), which > could be mapped to AsyncCallback or a few AsyncCallback derivatives > (and a hand-coded specialized exception to wrap the Error object). > > > I don't have to auto-generate > > 100% of the code, in the end there may always be some manual editing, > > but it's a pity. > > Right now (without constants) 90% of the generated wrapper for > > Google.GData compiles, the callbacks are the missing 10%. > > If AsyncCallback covers 90% of those 10%, it lefts only 1% or manual > editing ;-) > > (FYI, GWT-in-the-AIR is entirely hand-written)- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
