Thomas,

The fact that the JS libraries implement getters and setters is "nice"
for me because i don't have to worry about creating the getters and
setters, i can just mirror what is already in JS so it's one less
thing to worry about (in this case i have to since there may be
additional logic inside the getters and setters).

Oops, the setters don't need to return anything, the returns were left
in there for no good reason, thanks for pointing that out.

I realize that your getConstant approach has an initialization
overhead but i'm going to overlook that so that i can get the
generated library to a point where i can test it and then come back
and revisit this. This will be more complex because the GData JS
implementation allows "namespaces" to be loaded dynamically as needed.

On the return type of the JS methods that receive callbacks, most
likely these methods return void, i think that's just the way the
JSDocs display - otherwise they would have to display that as
void updateEntry(<google.gdata.Entry function(Object)> continuation,
<google.gdata.Entry function(Error)> opt_errorHandler).
This type of ambiguity is why an 100% auto-generate is not going to
happen - in addition to this there are a couple of classes missing
from the JS Docs (i'll just fill those in from the GData Java docs).

I like the idea of using an intermediate class to handle the
callbacks, i think you mentioned this in your original reply and i
missed it.

If you're interested, and since you already put some time here i can
add you as a member of this project:
http://code.google.com/p/gdata-gwt-client/
This way you get some credit. This is a key library for GWT in my
opinion and it's missing - Google says they don't have plans to do
this right now so it's a good opportunity. I need this GWT library for
a separate project: http://code.google.com/p/gdbe/

Bobby

On Apr 20, 10:14 am, Thomas Broyer <[email protected]> wrote:
> On 20 avr, 03:56, Bobby <[email protected]> wrote:
>
> > 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#getA...
>
> I'm not sure to understand why this "is nice" but, well, it seems to
> be the way the GData API has been written, so...
>
> > I wasn't aware that "return" wasn't necessary (though it makes sense),
> > this is why i ask stuff.
>
> Only when the Java method's return type is void!
>
> > 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/l...
>
> Note that this kind of initialization has an overhead: the class has a
> "clinit", so even if you do not use the constants at all in your code,
> there will be code to initialize them (won't be pruned by the compiler
> because of the JSNI, which could have side effects).
> I'll probably either move the constant fields into a Constants inner
> class (Event.Constants.ACTIVATE instead of Event.ACTIVATE) or use
> "true Java constants" (i.e. without JSNI), because the values for the
> constants are clearly documented.
>
> > 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.htmlhtt...
>
> > 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).
>
> How about using a com.google.gwt.user.client.Command instead?
>
>
>
>
>
> > 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);
>
> > }-*/
>
> (I'm perplex about the return type... isn't it rather the type of
> object passed to the continuation? looking at sample code and the doc,
> it seems like a problem with the JSDoc; updateEntry for instance would
> probably passe the Entry to the continuation, instead of returning an
> Entry --calls are asynchronous and the doc says "Returns: the new
> representation of the entry returned from the service.")
>
> public final native void getSelf(AsyncCallback<Entry> callback) /*-{
>    this.getSelf(function(entry) {
>         �[email protected]::handleCallback(Lcom/google/gwt/user/client/rpc/
> AsyncCallback;Ljava/lang/Object;)(callback, entry);
>       },
>       function(error) {
>         �[email protected]::handleError(Lcom/google/gwt/user/client/rpc/
> AsyncCallback;Lcom/google/gwt/core/JavaScriptObject;)(callback,
> error);
>       }
>    );
>
> }-*/
>
> with a class named Utils with the following static methods:
> @SuppressWarning("unchecked")
> private static void handleCallback(AsyncCallback cb, Object arg) {
>    // do the thing with UncaughtExceptionHandle, etc. resulting in:
>    // cb.onSuccess(arg);
>
> }
>
> @SuppressWarning("unchecked")
> private static void handleError(AsyncCallback cb, JavaScriptObject
> error) {
>    // same here.
>
> }
>
> Note that because the error in GData is a JavaScript Error object, you
> don't have to use a custom exception, you can just use a
> JavaScriptException:
>    cb.onFailure(new JavaScriptException(error));
>
> > 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 ;".
>
> Generics are handle by type erasure in Java, so you have to use the
> erasure type; use the Google Plugin for Eclipse, it provides
> autocompletion facilities and will flag errors if any.
>
> > 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).
>
> The pattern is simply:
> var that = this;
> this.method(function(a, b, c) {
>    [email protected]::onDone(III)(a, b, c);
>
>
>
> });- Hide quoted text -
>
> - Show quoted text -- 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 [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to