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 passed > > > > > > > > in from > > > > > > > > Java and it looked like a regular JS date - when printed, a > > > > > > > > regular > > > > > > > > date string is displayed. > > > > > > > > In web mode jUnit hangs on newInstance(new Date(), true/false) > > > > > > > > because > > > > > > > > a JS exception occurs. In hosted mode the following exception is > > > > > > > > thrown: > > > > > > > > > [WARN] Malformed JSNI reference 'getFullYear'; expect subsequent > > > > > > > > failures > > > > > > > > java.lang.NoSuchFieldError: getFullYear > > > > > > > > at com.google.gwt.dev.shell.CompilingClassLoader > > > > > > > > $DispatchClassInfoOracle.getDispId(CompilingClassLoader.java:119) > > > > > > > > at > > > > > > > > com.google.gwt.dev.shell.CompilingClassLoader.getDispId > > > > > > > > (CompilingClassLoader.java:531) > > > > > > > > at > > > > > > > > com.google.gwt.dev.shell.ie.IDispatchProxy.getIDsOfNames > > > > > > > > (IDispatchProxy.java:124) > > > > > > > > at > > > > > > > > com.google.gwt.dev.shell.ie.IDispatchImpl.GetIDsOfNames > > > > > > > > (IDispatchImpl.java:273) > > > > > > > > at com.google.gwt.dev.shell.ie.IDispatchImpl.method5 > > > > > > > > (IDispatchImpl.java:189) > > > > > > > > at org.eclipse.swt.internal.ole.win32.COMObject.callback5 > > > > > > > > (COMObject.java:108) > > > > > > > > at > > > > > > > > org.eclipse.swt.internal.ole.win32.COM.VtblCall(Native Method) > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
