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/EnumOptimizations
http://timepedia.blogspot.com/2009/04/gwts-type-system-is-more-powerful-than.html
> 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/data/extensions/Im.html
)
An example using an enum:
http://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/ltgt/gwt/air/core/client/html/HTMLLoader.java
http://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/ltgt/gwt/air/core/client/html/HTMLPDFCapability.java
An example using "just constants":
http://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/ltgt/gwt/air/core/client/events/Event.java
> 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)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
