One note about arrays. If a method in the API receives or returns an array, i currently make use of the JsArray class, which can go travel between JS and Java. I would prefer exposing these methods as receiving and returning actual arrays rather than JsArray, only because it's more generic (functionally there's little difference). I could make use of an array helper class that would convert a JsArray back and forth between a standard array, but if this will add some overhead (such as having to iterate through the array members) then it's probably not worth it. Any suggestions on this?
I expect to have a beta version of GWT-GData available for testing in less than 2 weeks, barring any surprises, since it's looking fairly good. Bobby On Jun 15, 2:53 am, Bobby <[email protected]> wrote: > I ended up updating the following classes to generics: > 1. com.google.gwt.gdata.client.atom.Feed > 2. com.google.gwt.gdata.client.Feed > 3. com.google.gwt.gdata.client.EventFeed > > The implementation is, respectively: > 1. public class Feed<E extends Entry> extends JavaScriptObject > 2. public class Feed<E extends Entry> extends > com.google.gwt.gdata.client.atom.Feed<E> > 3. public class EventFeed<E extends EventEntry> extends > com.google.gwt.gdata.client.Feed<E> > > The remaining Feed classes then extend one of these base Feed classes. > For example CalendarEventFeed: > public class CalendarEventFeed extends EventFeed<CalendarEventEntry> > > The good news is that there doesn't seem to be a need to override > parent class methods any longer but time will tell, which means the > class hierarchy stays the same, and the generics are alot neater. > > I also pointed the generator to the latest JS API version 1.10 and > there were no issues. Right now it's looking pretty good, so it's back > to testing. > > Bobby > > On Jun 14, 10:59 pm, Bobby <[email protected]> wrote: > > > I may be able to leave the inheritance in place without having > > problems with overrides by just adding generics. The Feed and Entry > > classes are the ones that are specialized in the API. The Java API has > > the Feed and Entry classes as generics, for > > example:http://code.google.com/apis/gdata/javadoc/com/google/gdata/data/calen... > > > The implementation of the base feed class would look like: > > public class Feed <F extends Feed, E extends Entry> extends > > JavaScriptObject { > > ... > > > } > > > If there are no issues in GWT this should be good. > > > Bobby > > > On Jun 14, 6:53 pm, Bobby <[email protected]> wrote: > > > > A few more comments. There's a new version of the GData JS API (1.10) > > > which is a little larger - luckily i should be able to point the code > > > generator to the new docs and be up to speed. Also, i had a closer > > > look at the Java, Python and .NET versions and they're all very out of > > > sync with eachother. > > > > The JS version seems to be the more extensive version (comparing for > > > example the number of classes within the Calendar namespace), even > > > though it's still missing a few namespaces, which tells me that it is > > > perhaps more active than the others. So the best i can do is try to > > > keep the GWT version as close to the JS version as possible and > > > completely ignore the Java version, which is quite different at this > > > point. > > > > Bobby > > > > On Jun 14, 2:28 am, Bobby <[email protected]> wrote: > > > > > A few classes from the "internal" namespaces are used directly: > > > > Link > > > > FeedLink > > > > DateTime > > > > Money > > > > PostalAddress > > > > PhoneNumber > > > > Organization > > > > Im > > > > ExtendedProperty > > > > Email > > > > Deleted > > > > Text > > > > Where > > > > Category > > > > > So if i were to convert those classes to interfaces, i would have to > > > > define specialized versions, which i'd rather not. An option is to > > > > leave all classes alone and just add a bunch of interfaces, one per > > > > class. So for example the following classes: > > > > com.google.gwt.gdata.client.Feed > > > > com.google.gwt.gdata.client.atom.Feed > > > > > Would implement the following interfaces respectively: > > > > com.google.gwt.gdata.client.impl.IFeed > > > > com.google.gwt.gdata.client.impl.atom.IFeed > > > > > Where the second interface extends the first, etc. > > > > > Since this can be added at any time, initially i'm going to keep the > > > > API flat without any inheritance or interfaces, so i'll have each > > > > class implement all of its methods, including those "inherited" from > > > > parent classes. Personally i think that to do this right, the GWT > > > > GData library should be built entirely with GWT rather than be > > > > overlayed on top of the JS API, which is a huge project. To take it > > > > one step at a time here's my plan: > > > > > 1. Build GWT-GData on top of JS API without class inheritance. > > > > 2. Add "inheritance" via interfaces. > > > > 3. Add the service namespaces that are missing from the JS API (e.g. > > > > Documents, YouTube, etc). > > > > 4. Remove the JS API and provide GWT implementation (as needed). > > > > > Bobby > > > > > On Jun 12, 1:46 pm, Bobby <[email protected]> wrote: > > > > > > Ok, so time to look at class structure. In the JS API we have for > > > > > example: > > > > > > com.google.gwt.gdata.client.calendar.CalendarFeed > > > > > com.google.gwt.gdata.client.Feed > > > > > com.google.gwt.gdata.client.atom.Feed > > > > > > We won't be able to implement this structure with overlay types > > > > > because all methods are final, so for example CalendarFeed can't > > > > > override methods of its parent feed classes - it does need to override > > > > > methods to specialize the parameter and return types. > > > > > > Most of the classes in the following namespaces are only used > > > > > internally. > > > > > com.google.gwt.gdata.client > > > > > com.google.gwt.gdata.client.atom > > > > > > The approach seems to be to not have any class in those namespaces > > > > > used directly. For example, the Calendar namespace does not use > > > > > com.google.gwt.gdata.client.Who, instead it specializes that class as > > > > > com.google.gwt.gdata.client.calendar.CalendarWho and uses that. > > > > > > So i have the following options: > > > > > 1. leave the parent classes around, but remove any methods implemented > > > > > by child classes (this leaves polymorphism in place, but it's not of > > > > > much use, since these classes will be pretty much empty). > > > > > 2. convert the parent classes to interfaces (this gives us useful > > > > > polymorphism) > > > > > 3. remove these parent classes from the GWT API. > > > > > > Option 1 is not very useful. > > > > > Option 2 works the best but perhaps adds too many interfaces. > > > > > Option 3 removes all of these internal classes, which gets rid of > > > > > polymorphism. With this approach, the GWT library would just have the > > > > > "leaves" of the GData API's class tree, which would result in a very > > > > > thin interface. > > > > > > I'm leaning towards Option 2 at this time. > > > > > > Bobby > > > > > > On Jun 6, 10:45 pm, Bobby <[email protected]> wrote: > > > > > > > The GoogleAccounts module is working well and is pretty close to > > > > > > what > > > > > > it needs to > > > > > > be:http://code.google.com/p/gwt-gdata/source/browse/trunk/gdata/src/com/... > > > > > > > I was able to create jUnit test cases that impersonate user > > > > > > authentication - the GData JS API AuthSub implementation performs > > > > > > authentication by redirecting to a Google Accounts page, performing > > > > > > auth and then redirecting back to the referring URL, passing along a > > > > > > session token which gets stored in a cookie. To make the > > > > > > authentication work i am setting the cookie directly which has the > > > > > > same effect but allows the jUnit tests to work > > > > > > smoothly:http://code.google.com/p/gwt-gdata/source/browse/trunk/gdata/test/com... > > > > > > > Now i can write unit tests for the services which read/write data > > > > > > with > > > > > > a test account. > > > > > > > I'm debating whether i should split the GWT-Gdata module into > > > > > > multiple > > > > > > sub modules. For example, instead of having one large GWT module at > > > > > > com.google.gwt.gdata, have com.google.gwt.gdata be a base module > > > > > > inherited by specialized modules such as: > > > > > > > com.google.gwt.gdata.calendar > > > > > > com.google.gwt.gdata.blogger > > > > > > com.google.gwt.gdata.contacts > > > > > > com.google.gwt.gdata.finance > > > > > > ...etc > > > > > > > The reason is that, from my experience, you end up using GData to > > > > > > interact with either Calendar or Documents for example, rather than > > > > > > all of the GData systems, so it seems more natural to have a module > > > > > > per GData system. > > > > > > > Bobby > > > > > > > On May 30, 10:21 pm, Bobby <[email protected]> wrote: > > > > > > > > I eliminated the Date errors by making use of a > > > > > > > DateHelper:http://code.google.com/p/gwt-gdata/source/browse/trunk/gdata/src/com/... > > > > > > > > Here's how i'm using > > > > > > > it:http://code.google.com/p/gwt-gdata/source/browse/trunk/gdata/src/com/... > > > > > > > > I convert Dates to milliseconds since 1970 before passing them > > > > > > > between > > > > > > > Java and JS. > > > > > > > > Bobby > > > > > > > > On May 30, 5:04 pm, Eric Ayers <[email protected]> wrote: > > > > > > > > > I don't think GWT does anything useful when you pass a Java Date > > > > > > > > object into JSNI. You may want to pass the # of milliseconds > > > > > > > > since > > > > > > > > 1970 instead. > > > > > > > > > On Sat, May 30, 2009 at 2:03 AM, Bobby <[email protected]> > > > > > > > > wrote: > > > > > > > > > > I'm seeing some weird behavior whenever java.util.Date is > > > > > > > > > used. The > > > > > > > > > following DateTime class in GData wraps around a date: > > > > > > > > >http://code.google.com/p/gwt-gdata/source/browse/trunk/gdata/src/com/... > > > > > > > > > > The newInstance method receives a java.util.Date.: > > > > > > > > > > public static native DateTime newInstance(Date date, boolean > > > > > > > > > dateOnly) /*-{ > > > > > > > > > return new $wnd.google.gdata.DateTime( > > > > > > > > > date, > > > > > > > > > dateOnly > > > > > > > > > ); > > > > > > > > > }-*/; > > > > > > > > > > Whenever i call this method it fails. If i replace it with the > > > > > > > > > following, then it works: > > > > > > > > > > public static native DateTime newInstance(Date date, boolean > > > > > > > > > dateOnly) /*-{ > > > > > > > > > return new $wnd.google.gdata.DateTime( > > > > > > > > > new Date(), //pass static JS date instead > > > > > > > > > dateOnly > > > > > > > > > ); > > > > > > > > > }-*/; > > > > > > > > > > So the date object passed in from Java causes a failure > > > > > > > > > whereas a > > > > > > > > > regular JS date doesn't. I looked at the Date parameter > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
