GWT FileUpload
Hello, I have issues with GWT fileUpload in Internet Explorer. in the onSubmitComplete ,event.getResult() is not giving me the XML with values.It is just giving me the XML skeleton without valuse. It works fine in Chrome,but failing in InternetExplorer. Does anyone have this kind of issue? Please help with a work around for IE. Regards, Bobby -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/nSyWtDiFA0gJ. 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.
GWT textbox.
onFocus of any of the textboxes in my GWT application the cursor is going back to the starting of the text. I tried to set the cursor position but still didnt work. Even i cannot be able to select the text by dragging the mouse over the text. This happens only in IE ,works fine in Chrome. Please provide with a solution guys.. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/o13Y8F5ym_cJ. 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.
GWT listbox not working with single click.
When I click on the listbox in IE it doesnt open for the single click.It works fine in Chrome. Please help with any solution for this problem -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/k910Jep6ltQJ. 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.
GDBE - Build a custom Google Docs Editor
GDBE is an open source project providing a basic text editor for Google Docs: http://code.google.com/p/gdbe/ You can check out the live version here: http://gdocs-base-editor.appspot.com/ It's built with GWT and the AppEngine, just upload to your AppEngine account and you'll have a working editor. We can use GDBE to build customized document editors, for example: http://docs.latexlab.org If you're interested, check out the source and make it your own. :) Enjoy Bobby -- 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-tool...@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.
GWT Bindings for Google Map Utilities
If you use the gwt-maps library to add map capabilities to your GWT apps then you might also be interested in the gwt-maps-utility library, it extends the gwt-maps library with some useful map utilities: http://code.google.com/p/gwt-maps-utility/ Samples are available as well: http://gwt-maps-utility.appspot.com/samples/v1.0/HelloMapsUtility.html Bobby -- 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-tool...@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.
stock trading + live rates
I have a desktop app that I would like to port to a gwt web app. The problem is I am confused on how I would serve up live streaming rates to the new app. Currently i have a c++ application that makes a tcp connection to my broker, subscribes to rates, and then receives updates any time the price changes. It seems like web sockets would be the way to go but how can i get the data from a C++ app to the java web app? Hopefully that is not too vague. -- 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-tool...@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.
candle stick charts
Anyone have any experience with creating candlestick charts with GWT? Thanks, Bobby --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
candle stick charts
Seems to be no good way to create candlestick charts (stock charts) with GWT. I noticed the chart API provides the option but does not integrate with GWT (although I think I saw a third party library, ill look more into that today). The visualization API does not allow it, at least as far as I can tell. I can create the chart I want with the gwt-canvas package but it does not appear that I can add text. So there are ways to do it but none that I can see are complete. Anyone have any experience with this? Thanks, Bobby --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Version 2.0.1 will be available probably later this month. The IE bug
is gone, which is nice since it makes it possible to use the
AjaxLoader module, which eliminates the need for a script tag and
simplifies loading packages individually.
The samples for 2.0.1 dynamically load packages as needed:
http://gwt-gdata.appspot.com/v2.0.1/HelloGData.html
By the way, even though i've used static initializers for constants,
i'm not seeing any initialization cost. I think maybe GWT is inlining
the initializers, since the initializers are native methods on overlay
types.
Bobby
On Aug 24, 3:36 am, Bobby wrote:
> Version 1.10.1 is available
> here:http://code.google.com/p/gwt-gdata/downloads/list
>
> Bobby
>
> On Aug 14, 4:53 am, Bobby wrote:
>
> > I may not be able to correct this IE bug, and it may not be desirable
> > either since it isn't a good idea to have the GWT version introduce
> > hacks onto the JS library in order to fix a bug - stuff like this is
> > better off being corrected in the JS version directly. I'll add this
> > as a defect and deal with it later, the workaround being to use a
> > script reference to load the API.
>
> > I'm starting to think about how to detach the GWT library from the JS
> > api in the future. Here's what i'm seeing, in the JS API all GData
> > operations (POST, PUT, DELETE) are sent as POST commands. A POST
> > variable called HTTP-Method-Override can be used to specify the actual
> > operation. Cross-domain POSTS aren't a problem, we can just create and
> > submit a hidden form using some JavaScript.
>
> > Since GData supports retrieving data in JSON format, we can use a
> > JSONP approach to do cross domain reads - this is what the current JS
> > API does.
>
> > This means that in order to detach the GWT version from the JS
> > libraries we have to:
> > 1. identify the Atom schema for each data type, there are a few
> > hundred classes.
> > 2. provide a base implementation that can perform cross-domain POSTS
> > and JSONP reads.
>
> > I think #1 can be automated and #2 is sensitive but small.
>
> > The end result will be a more GWT-optimizable API which can then grow
> > at its own pace. The samples and unit tests wouldn't change
> > significantly, if at all. We can still use overlay types to wrap
> > around the JSON objects returned from GData. I've taken a closer look
> > at the GData Java library and i don't think that the GWT and Java APIs
> > will ever match because the GWT version will need to be callback-based
> > whereas Java doesn't have this limitation.
>
> > Anyway, just some thoughts.
>
> > Bobby
>
> > On Aug 14, 2:53 am, Bobby wrote:
>
> > > There are some quirks which are making it difficult to narrow down the
> > > reason why AuthSub fails in IE. So far i know it only happens when
> > > google.load is used with a callback, even when google.load is called
> > > while the page is being loaded.
>
> > > So something like the following:
> > >
> > >
> > > google.load("gdata", "1.10", myCallback);
> > >
> > >
> > >
>
> > > Will always see the following behavior:
> > > 1. User clicks to login.
> > > 2. User is redirect to authorization page and clicks to authorize.
> > > 3. User is redirected back to the original page, with a token appended
> > > in the URL.
> > > 4. Page doesn't consume the token in the URL (the correct behavior is
> > > for the page to place the token in a cookie and remove the token from
> > > the url).
> > > 5. User clicks to login again.
> > > 6. User gets redirected to authorization page again, and steps 3-6 are
> > > repeated an arbitrary number of times.
> > > 7. If, after reaching the authorization page a second time, the user
> > > clicks the browser's back button, causing the browser to go back to
> > > the page that contains the token in the url, the token is successfully
> > > consumed and the user is successfully logged in. Go figure.
>
> > > Why "backing" into the page causes GData to successfully consume the
> > > token i have no idea - especially since refreshing the page at step 4
> > > has no effect.
>
> > > My guess is that when backing into the page IE will use a cached
> > > version of the GData script, which is processed immediately and may
> > > make the difference.
>
> > > Bobby
>
> > > On Aug 14, 1:37 am, Bobby wrote:
>
> > > > This was outs
Re: GWT 1.7.1 with tomcat 5.5
Have you found a solution to this issue? We are having a similar problem with GWT not showing in Firefox 3. Thanks Bobby Berry On Sep 30, 1:06 am, muhannad nasser wrote: > hi > i am trying to run the sample GWT project in hosted mode using tomcat > my workspace for eclipse 3.5 is the webapp for the tomcat > and by default the WEB-INF is inside the war folder > > the tree > > webapp > | > projectName > | > src > | > war > | > WEB-INF > | > classes > | > lib > > my tomcat is running at port 9090 > but when i try to run it on firefox using this > url:http://localhost:9090/projectName > > it does not show anything. put when i run it using host mode from > the eclipse it works fine > > can anyone help me please > > thanks > > -- > ~~~With Regards~~~ > Muhannad Dar-Nasser > ~~Computer Systems Engineering~~ > ~~My Blog:http://mhand7.blogspot.com~~ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Version 1.10.1 is available here:
http://code.google.com/p/gwt-gdata/downloads/list
Bobby
On Aug 14, 4:53 am, Bobby wrote:
> I may not be able to correct this IE bug, and it may not be desirable
> either since it isn't a good idea to have the GWT version introduce
> hacks onto the JS library in order to fix a bug - stuff like this is
> better off being corrected in the JS version directly. I'll add this
> as a defect and deal with it later, the workaround being to use a
> script reference to load the API.
>
> I'm starting to think about how to detach the GWT library from the JS
> api in the future. Here's what i'm seeing, in the JS API all GData
> operations (POST, PUT, DELETE) are sent as POST commands. A POST
> variable called HTTP-Method-Override can be used to specify the actual
> operation. Cross-domain POSTS aren't a problem, we can just create and
> submit a hidden form using some JavaScript.
>
> Since GData supports retrieving data in JSON format, we can use a
> JSONP approach to do cross domain reads - this is what the current JS
> API does.
>
> This means that in order to detach the GWT version from the JS
> libraries we have to:
> 1. identify the Atom schema for each data type, there are a few
> hundred classes.
> 2. provide a base implementation that can perform cross-domain POSTS
> and JSONP reads.
>
> I think #1 can be automated and #2 is sensitive but small.
>
> The end result will be a more GWT-optimizable API which can then grow
> at its own pace. The samples and unit tests wouldn't change
> significantly, if at all. We can still use overlay types to wrap
> around the JSON objects returned from GData. I've taken a closer look
> at the GData Java library and i don't think that the GWT and Java APIs
> will ever match because the GWT version will need to be callback-based
> whereas Java doesn't have this limitation.
>
> Anyway, just some thoughts.
>
> Bobby
>
> On Aug 14, 2:53 am, Bobby wrote:
>
> > There are some quirks which are making it difficult to narrow down the
> > reason why AuthSub fails in IE. So far i know it only happens when
> > google.load is used with a callback, even when google.load is called
> > while the page is being loaded.
>
> > So something like the following:
> >
> >
> > google.load("gdata", "1.10", myCallback);
> >
> >
> >
>
> > Will always see the following behavior:
> > 1. User clicks to login.
> > 2. User is redirect to authorization page and clicks to authorize.
> > 3. User is redirected back to the original page, with a token appended
> > in the URL.
> > 4. Page doesn't consume the token in the URL (the correct behavior is
> > for the page to place the token in a cookie and remove the token from
> > the url).
> > 5. User clicks to login again.
> > 6. User gets redirected to authorization page again, and steps 3-6 are
> > repeated an arbitrary number of times.
> > 7. If, after reaching the authorization page a second time, the user
> > clicks the browser's back button, causing the browser to go back to
> > the page that contains the token in the url, the token is successfully
> > consumed and the user is successfully logged in. Go figure.
>
> > Why "backing" into the page causes GData to successfully consume the
> > token i have no idea - especially since refreshing the page at step 4
> > has no effect.
>
> > My guess is that when backing into the page IE will use a cached
> > version of the GData script, which is processed immediately and may
> > make the difference.
>
> > Bobby
>
> > On Aug 14, 1:37 am, Bobby wrote:
>
> > > This was outside GWT. I'm trying to find the cause of the IE AuthSub
> > > issue outside of GWT first. Basically, when google.load() is called
> > > after the page has finished loading - such as from a button click,
> > > AuthSub doesn't succeed.
>
> > > Bobby
>
> > > On Aug 14, 12:17 am, Eric Ayers wrote:
>
> > > > If you are calling JavaScript inside of a GWT JSNI function, you
> > > > should be using $wnd.google.load(...)
>
> > > > On Thu, Aug 13, 2009 at 11:55 PM, Bobby wrote:
>
> > > > > This IE AuthSub issue is not because of the IFrame, the transferToken
> > > > > approach didn't make a difference.
>
> > > > > I tried placing the google.load('gdata', '1.10'); call in a button
> > > > > click event. Here's the code:
> > > > >
> > > > >
> > > &g
Re: GWT best Practices - JS Library Wrappers & Overlay Types
I may not be able to correct this IE bug, and it may not be desirable
either since it isn't a good idea to have the GWT version introduce
hacks onto the JS library in order to fix a bug - stuff like this is
better off being corrected in the JS version directly. I'll add this
as a defect and deal with it later, the workaround being to use a
script reference to load the API.
I'm starting to think about how to detach the GWT library from the JS
api in the future. Here's what i'm seeing, in the JS API all GData
operations (POST, PUT, DELETE) are sent as POST commands. A POST
variable called HTTP-Method-Override can be used to specify the actual
operation. Cross-domain POSTS aren't a problem, we can just create and
submit a hidden form using some JavaScript.
Since GData supports retrieving data in JSON format, we can use a
JSONP approach to do cross domain reads - this is what the current JS
API does.
This means that in order to detach the GWT version from the JS
libraries we have to:
1. identify the Atom schema for each data type, there are a few
hundred classes.
2. provide a base implementation that can perform cross-domain POSTS
and JSONP reads.
I think #1 can be automated and #2 is sensitive but small.
The end result will be a more GWT-optimizable API which can then grow
at its own pace. The samples and unit tests wouldn't change
significantly, if at all. We can still use overlay types to wrap
around the JSON objects returned from GData. I've taken a closer look
at the GData Java library and i don't think that the GWT and Java APIs
will ever match because the GWT version will need to be callback-based
whereas Java doesn't have this limitation.
Anyway, just some thoughts.
Bobby
On Aug 14, 2:53 am, Bobby wrote:
> There are some quirks which are making it difficult to narrow down the
> reason why AuthSub fails in IE. So far i know it only happens when
> google.load is used with a callback, even when google.load is called
> while the page is being loaded.
>
> So something like the following:
>
>
> google.load("gdata", "1.10", myCallback);
>
>
>
>
> Will always see the following behavior:
> 1. User clicks to login.
> 2. User is redirect to authorization page and clicks to authorize.
> 3. User is redirected back to the original page, with a token appended
> in the URL.
> 4. Page doesn't consume the token in the URL (the correct behavior is
> for the page to place the token in a cookie and remove the token from
> the url).
> 5. User clicks to login again.
> 6. User gets redirected to authorization page again, and steps 3-6 are
> repeated an arbitrary number of times.
> 7. If, after reaching the authorization page a second time, the user
> clicks the browser's back button, causing the browser to go back to
> the page that contains the token in the url, the token is successfully
> consumed and the user is successfully logged in. Go figure.
>
> Why "backing" into the page causes GData to successfully consume the
> token i have no idea - especially since refreshing the page at step 4
> has no effect.
>
> My guess is that when backing into the page IE will use a cached
> version of the GData script, which is processed immediately and may
> make the difference.
>
> Bobby
>
> On Aug 14, 1:37 am, Bobby wrote:
>
> > This was outside GWT. I'm trying to find the cause of the IE AuthSub
> > issue outside of GWT first. Basically, when google.load() is called
> > after the page has finished loading - such as from a button click,
> > AuthSub doesn't succeed.
>
> > Bobby
>
> > On Aug 14, 12:17 am, Eric Ayers wrote:
>
> > > If you are calling JavaScript inside of a GWT JSNI function, you
> > > should be using $wnd.google.load(...)
>
> > > On Thu, Aug 13, 2009 at 11:55 PM, Bobby wrote:
>
> > > > This IE AuthSub issue is not because of the IFrame, the transferToken
> > > > approach didn't make a difference.
>
> > > > I tried placing the google.load('gdata', '1.10'); call in a button
> > > > click event. Here's the code:
> > > >
> > > >
> > > >
> > > > http://www.google.com/jsapi"</a>;></
> > > > script>
> > > > <script type="text/javascript">
> > > > function loadGData() {
> > > > google.load('gdata', '1.10');
> > > > }
> > > >
> > > >
> > > >
> > > >
>
> > > > If you try this, when you click "Load GData", the page is cleared and
> > > > not
Re: GWT best Practices - JS Library Wrappers & Overlay Types
There are some quirks which are making it difficult to narrow down the
reason why AuthSub fails in IE. So far i know it only happens when
google.load is used with a callback, even when google.load is called
while the page is being loaded.
So something like the following:
google.load("gdata", "1.10", myCallback);
Will always see the following behavior:
1. User clicks to login.
2. User is redirect to authorization page and clicks to authorize.
3. User is redirected back to the original page, with a token appended
in the URL.
4. Page doesn't consume the token in the URL (the correct behavior is
for the page to place the token in a cookie and remove the token from
the url).
5. User clicks to login again.
6. User gets redirected to authorization page again, and steps 3-6 are
repeated an arbitrary number of times.
7. If, after reaching the authorization page a second time, the user
clicks the browser's back button, causing the browser to go back to
the page that contains the token in the url, the token is successfully
consumed and the user is successfully logged in. Go figure.
Why "backing" into the page causes GData to successfully consume the
token i have no idea - especially since refreshing the page at step 4
has no effect.
My guess is that when backing into the page IE will use a cached
version of the GData script, which is processed immediately and may
make the difference.
Bobby
On Aug 14, 1:37 am, Bobby wrote:
> This was outside GWT. I'm trying to find the cause of the IE AuthSub
> issue outside of GWT first. Basically, when google.load() is called
> after the page has finished loading - such as from a button click,
> AuthSub doesn't succeed.
>
> Bobby
>
> On Aug 14, 12:17 am, Eric Ayers wrote:
>
> > If you are calling JavaScript inside of a GWT JSNI function, you
> > should be using $wnd.google.load(...)
>
> > On Thu, Aug 13, 2009 at 11:55 PM, Bobby wrote:
>
> > > This IE AuthSub issue is not because of the IFrame, the transferToken
> > > approach didn't make a difference.
>
> > > I tried placing the google.load('gdata', '1.10'); call in a button
> > > click event. Here's the code:
> > >
> > >
> > >
> > > http://www.google.com/jsapi"</a>;></
> > > script>
> > > <script type="text/javascript">
> > > function loadGData() {
> > > google.load('gdata', '1.10');
> > > }
> > >
> > >
> > >
> > >
>
> > > If you try this, when you click "Load GData", the page is cleared and
> > > nothing really happens. If you look at the page source after clicking
> > > the button you see the following:
> > > http://www.google.com/uds/?file=gdata&v=1.10"</a>; type="text/
> > > javascript">
>
> > > This is what would happen if document.write was being used and would
> > > explain a few things.
>
> > > Eric, does your AjaxLoader module use google.load() from the jsapi?
>
> > > Bobby
>
> > > On Aug 13, 10:20 pm, Bobby wrote:
> > >> By the way, i've finished porting the samples (70 of them) i'm
> > >> currently polishing and commenting the samples code.
>
> > >> I've added specialized Callbacks into the API, for example
> > >> BlogEntryCallback (extending AsyncCallback) - this meant
> > >> adding specialized methods for insert/update/delete, but makes for a
> > >> better API. There have been other changes and design choices as well.
>
> > >> In the Maps samples, the create/update features are not working
> > >> because of a KML-related defect which i might try to get around with
> > >> GWT:http://code.google.com/p/gmaps-api-issues/issues/detail?id=1585
>
> > >> Other than that i have a small list of items to wrap up (including
> > >> this IE issue) and some documentation to write, but nothing major and
> > >> i'm counting on having a download by the end of this week or next week
> > >> at the latest.
>
> > >> Bobby
>
> > >> On Aug 13, 9:46 pm, Bobby wrote:
>
> > >> > The onModuleLoad is within an iframe, that's probably the cause. I
> > >> > think i can find a way around this. For example, i can add the
> > >> > following method to the GData module:
> > >> > GData.transferTokenOrSomething();
>
> > >> > This function would check the top frame for a token and append it to
> > >>
Re: GWT best Practices - JS Library Wrappers & Overlay Types
This was outside GWT. I'm trying to find the cause of the IE AuthSub
issue outside of GWT first. Basically, when google.load() is called
after the page has finished loading - such as from a button click,
AuthSub doesn't succeed.
Bobby
On Aug 14, 12:17 am, Eric Ayers wrote:
> If you are calling JavaScript inside of a GWT JSNI function, you
> should be using $wnd.google.load(...)
>
>
>
> On Thu, Aug 13, 2009 at 11:55 PM, Bobby wrote:
>
> > This IE AuthSub issue is not because of the IFrame, the transferToken
> > approach didn't make a difference.
>
> > I tried placing the google.load('gdata', '1.10'); call in a button
> > click event. Here's the code:
> >
> >
> >
> > http://www.google.com/jsapi"</a>;></
> > script>
> > <script type="text/javascript">
> > function loadGData() {
> > google.load('gdata', '1.10');
> > }
> >
> >
> >
> >
>
> > If you try this, when you click "Load GData", the page is cleared and
> > nothing really happens. If you look at the page source after clicking
> > the button you see the following:
> > http://www.google.com/uds/?file=gdata&v=1.10"</a>; type="text/
> > javascript">
>
> > This is what would happen if document.write was being used and would
> > explain a few things.
>
> > Eric, does your AjaxLoader module use google.load() from the jsapi?
>
> > Bobby
>
> > On Aug 13, 10:20 pm, Bobby wrote:
> >> By the way, i've finished porting the samples (70 of them) i'm
> >> currently polishing and commenting the samples code.
>
> >> I've added specialized Callbacks into the API, for example
> >> BlogEntryCallback (extending AsyncCallback) - this meant
> >> adding specialized methods for insert/update/delete, but makes for a
> >> better API. There have been other changes and design choices as well.
>
> >> In the Maps samples, the create/update features are not working
> >> because of a KML-related defect which i might try to get around with
> >> GWT:http://code.google.com/p/gmaps-api-issues/issues/detail?id=1585
>
> >> Other than that i have a small list of items to wrap up (including
> >> this IE issue) and some documentation to write, but nothing major and
> >> i'm counting on having a download by the end of this week or next week
> >> at the latest.
>
> >> Bobby
>
> >> On Aug 13, 9:46 pm, Bobby wrote:
>
> >> > The onModuleLoad is within an iframe, that's probably the cause. I
> >> > think i can find a way around this. For example, i can add the
> >> > following method to the GData module:
> >> > GData.transferTokenOrSomething();
>
> >> > This function would check the top frame for a token and append it to
> >> > the IFrame's location. I'll play around with this.
>
> >> > Bobby
>
> >> > On Aug 13, 9:29 pm, Bobby wrote:
>
> >> > > Another possible cause could be for example if, in the compiled GWT
> >> > > app, the google.load call happens inside an IFrame.
>
> >> > > Currently, with google.load being called from onModuleLoad,
> >> > > google.accounts.user.login() causes the redirect to the Google
> >> > > Accounts authorization page, but when it redirects back, with the
> >> > > token in the URL (for example /HelloGData.html#tokenhere), the token
> >> > > doesn't get consumed (in IE), and the authentication doesn't succeed.
>
> >> > > If GWT is placing the onModuleLoad code inside an IFrame, then it may
> >> > > cause the GData library to look for the token on the IFrame
> >> > > window.location, instead of the top's window.location.
>
> >> > > Bobby
>
> >> > > On Aug 13, 9:16 pm, Eric Ayers wrote:
>
> >> > > > The gdata init shouldn't use document.write() - you should be able to
> >> > > > call it at any time.
>
> >> > > > There is a tradeoff of using the AjaxLoader module - it does add more
> >> > > > delay than using the script version. Fortunately, you can code your
> >> > > > app using AjaxLoader and then if you need the speedup, just add the
> >> > > > logic in your host page. AjaxLoader will detect that the jsapi is
> >> > > > already there and bypass it. You can add that check in your version
> >> > > > of GData.loadGDataApi() if you like.
>
> >> > > > On Thu, Aug 13, 2009 at 9:11 PM, Bobby wrote:
>
> >> > > > > In the GData JS library, in IE, AuthSub fails if
> >> > > > > google.load("gdata",
> >> > > > > "1.10"); is asynchronous, after the page has finished processing.
> >> > > > > For
> >> > > > > example, if i place the google.load("gdata", "1.10"); call within
> >> > > > > the
> >> > > > > GWT onModuleLoad method, then AuthSub stops halfway.
>
> >> > > > > To avoid this we can directly add the following at the top of the
> >> > > > > GWT
> >> > > > > html page:
> >> > > > >
Re: GWT best Practices - JS Library Wrappers & Overlay Types
This IE AuthSub issue is not because of the IFrame, the transferToken
approach didn't make a difference.
I tried placing the google.load('gdata', '1.10'); call in a button
click event. Here's the code:
http://www.google.com/jsapi"</a>;>
function loadGData() {
google.load('gdata', '1.10');
}
If you try this, when you click "Load GData", the page is cleared and
nothing really happens. If you look at the page source after clicking
the button you see the following:
http://www.google.com/uds/?file=gdata&v=1.10"</a>; type="text/
javascript">
This is what would happen if document.write was being used and would
explain a few things.
Eric, does your AjaxLoader module use google.load() from the jsapi?
Bobby
On Aug 13, 10:20 pm, Bobby wrote:
> By the way, i've finished porting the samples (70 of them) i'm
> currently polishing and commenting the samples code.
>
> I've added specialized Callbacks into the API, for example
> BlogEntryCallback (extending AsyncCallback) - this meant
> adding specialized methods for insert/update/delete, but makes for a
> better API. There have been other changes and design choices as well.
>
> In the Maps samples, the create/update features are not working
> because of a KML-related defect which i might try to get around with
> GWT:http://code.google.com/p/gmaps-api-issues/issues/detail?id=1585
>
> Other than that i have a small list of items to wrap up (including
> this IE issue) and some documentation to write, but nothing major and
> i'm counting on having a download by the end of this week or next week
> at the latest.
>
> Bobby
>
> On Aug 13, 9:46 pm, Bobby wrote:
>
> > The onModuleLoad is within an iframe, that's probably the cause. I
> > think i can find a way around this. For example, i can add the
> > following method to the GData module:
> > GData.transferTokenOrSomething();
>
> > This function would check the top frame for a token and append it to
> > the IFrame's location. I'll play around with this.
>
> > Bobby
>
> > On Aug 13, 9:29 pm, Bobby wrote:
>
> > > Another possible cause could be for example if, in the compiled GWT
> > > app, the google.load call happens inside an IFrame.
>
> > > Currently, with google.load being called from onModuleLoad,
> > > google.accounts.user.login() causes the redirect to the Google
> > > Accounts authorization page, but when it redirects back, with the
> > > token in the URL (for example /HelloGData.html#tokenhere), the token
> > > doesn't get consumed (in IE), and the authentication doesn't succeed.
>
> > > If GWT is placing the onModuleLoad code inside an IFrame, then it may
> > > cause the GData library to look for the token on the IFrame
> > > window.location, instead of the top's window.location.
>
> > > Bobby
>
> > > On Aug 13, 9:16 pm, Eric Ayers wrote:
>
> > > > The gdata init shouldn't use document.write() - you should be able to
> > > > call it at any time.
>
> > > > There is a tradeoff of using the AjaxLoader module - it does add more
> > > > delay than using the script version. Fortunately, you can code your
> > > > app using AjaxLoader and then if you need the speedup, just add the
> > > > logic in your host page. AjaxLoader will detect that the jsapi is
> > > > already there and bypass it. You can add that check in your version
> > > > of GData.loadGDataApi() if you like.
>
> > > > On Thu, Aug 13, 2009 at 9:11 PM, Bobby wrote:
>
> > > > > In the GData JS library, in IE, AuthSub fails if google.load("gdata",
> > > > > "1.10"); is asynchronous, after the page has finished processing. For
> > > > > example, if i place the google.load("gdata", "1.10"); call within the
> > > > > GWT onModuleLoad method, then AuthSub stops halfway.
>
> > > > > To avoid this we can directly add the following at the top of the GWT
> > > > > html page:
> > > > >
Re: GWT best Practices - JS Library Wrappers & Overlay Types
By the way, i've finished porting the samples (70 of them) i'm
currently polishing and commenting the samples code.
I've added specialized Callbacks into the API, for example
BlogEntryCallback (extending AsyncCallback) - this meant
adding specialized methods for insert/update/delete, but makes for a
better API. There have been other changes and design choices as well.
In the Maps samples, the create/update features are not working
because of a KML-related defect which i might try to get around with
GWT:
http://code.google.com/p/gmaps-api-issues/issues/detail?id=1585
Other than that i have a small list of items to wrap up (including
this IE issue) and some documentation to write, but nothing major and
i'm counting on having a download by the end of this week or next week
at the latest.
Bobby
On Aug 13, 9:46 pm, Bobby wrote:
> The onModuleLoad is within an iframe, that's probably the cause. I
> think i can find a way around this. For example, i can add the
> following method to the GData module:
> GData.transferTokenOrSomething();
>
> This function would check the top frame for a token and append it to
> the IFrame's location. I'll play around with this.
>
> Bobby
>
> On Aug 13, 9:29 pm, Bobby wrote:
>
> > Another possible cause could be for example if, in the compiled GWT
> > app, the google.load call happens inside an IFrame.
>
> > Currently, with google.load being called from onModuleLoad,
> > google.accounts.user.login() causes the redirect to the Google
> > Accounts authorization page, but when it redirects back, with the
> > token in the URL (for example /HelloGData.html#tokenhere), the token
> > doesn't get consumed (in IE), and the authentication doesn't succeed.
>
> > If GWT is placing the onModuleLoad code inside an IFrame, then it may
> > cause the GData library to look for the token on the IFrame
> > window.location, instead of the top's window.location.
>
> > Bobby
>
> > On Aug 13, 9:16 pm, Eric Ayers wrote:
>
> > > The gdata init shouldn't use document.write() - you should be able to
> > > call it at any time.
>
> > > There is a tradeoff of using the AjaxLoader module - it does add more
> > > delay than using the script version. Fortunately, you can code your
> > > app using AjaxLoader and then if you need the speedup, just add the
> > > logic in your host page. AjaxLoader will detect that the jsapi is
> > > already there and bypass it. You can add that check in your version
> > > of GData.loadGDataApi() if you like.
>
> > > On Thu, Aug 13, 2009 at 9:11 PM, Bobby wrote:
>
> > > > In the GData JS library, in IE, AuthSub fails if google.load("gdata",
> > > > "1.10"); is asynchronous, after the page has finished processing. For
> > > > example, if i place the google.load("gdata", "1.10"); call within the
> > > > GWT onModuleLoad method, then AuthSub stops halfway.
>
> > > > To avoid this we can directly add the following at the top of the GWT
> > > > html page:
> > > >
Re: GWT best Practices - JS Library Wrappers & Overlay Types
The onModuleLoad is within an iframe, that's probably the cause. I
think i can find a way around this. For example, i can add the
following method to the GData module:
GData.transferTokenOrSomething();
This function would check the top frame for a token and append it to
the IFrame's location. I'll play around with this.
Bobby
On Aug 13, 9:29 pm, Bobby wrote:
> Another possible cause could be for example if, in the compiled GWT
> app, the google.load call happens inside an IFrame.
>
> Currently, with google.load being called from onModuleLoad,
> google.accounts.user.login() causes the redirect to the Google
> Accounts authorization page, but when it redirects back, with the
> token in the URL (for example /HelloGData.html#tokenhere), the token
> doesn't get consumed (in IE), and the authentication doesn't succeed.
>
> If GWT is placing the onModuleLoad code inside an IFrame, then it may
> cause the GData library to look for the token on the IFrame
> window.location, instead of the top's window.location.
>
> Bobby
>
> On Aug 13, 9:16 pm, Eric Ayers wrote:
>
> > The gdata init shouldn't use document.write() - you should be able to
> > call it at any time.
>
> > There is a tradeoff of using the AjaxLoader module - it does add more
> > delay than using the script version. Fortunately, you can code your
> > app using AjaxLoader and then if you need the speedup, just add the
> > logic in your host page. AjaxLoader will detect that the jsapi is
> > already there and bypass it. You can add that check in your version
> > of GData.loadGDataApi() if you like.
>
> > On Thu, Aug 13, 2009 at 9:11 PM, Bobby wrote:
>
> > > In the GData JS library, in IE, AuthSub fails if google.load("gdata",
> > > "1.10"); is asynchronous, after the page has finished processing. For
> > > example, if i place the google.load("gdata", "1.10"); call within the
> > > GWT onModuleLoad method, then AuthSub stops halfway.
>
> > > To avoid this we can directly add the following at the top of the GWT
> > > html page:
> > >
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Another possible cause could be for example if, in the compiled GWT
app, the google.load call happens inside an IFrame.
Currently, with google.load being called from onModuleLoad,
google.accounts.user.login() causes the redirect to the Google
Accounts authorization page, but when it redirects back, with the
token in the URL (for example /HelloGData.html#tokenhere), the token
doesn't get consumed (in IE), and the authentication doesn't succeed.
If GWT is placing the onModuleLoad code inside an IFrame, then it may
cause the GData library to look for the token on the IFrame
window.location, instead of the top's window.location.
Bobby
On Aug 13, 9:16 pm, Eric Ayers wrote:
> The gdata init shouldn't use document.write() - you should be able to
> call it at any time.
>
> There is a tradeoff of using the AjaxLoader module - it does add more
> delay than using the script version. Fortunately, you can code your
> app using AjaxLoader and then if you need the speedup, just add the
> logic in your host page. AjaxLoader will detect that the jsapi is
> already there and bypass it. You can add that check in your version
> of GData.loadGDataApi() if you like.
>
>
>
> On Thu, Aug 13, 2009 at 9:11 PM, Bobby wrote:
>
> > In the GData JS library, in IE, AuthSub fails if google.load("gdata",
> > "1.10"); is asynchronous, after the page has finished processing. For
> > example, if i place the google.load("gdata", "1.10"); call within the
> > GWT onModuleLoad method, then AuthSub stops halfway.
>
> > To avoid this we can directly add the following at the top of the GWT
> > html page:
> >
Re: GWT best Practices - JS Library Wrappers & Overlay Types
In the GData JS library, in IE, AuthSub fails if google.load("gdata",
"1.10"); is asynchronous, after the page has finished processing. For
example, if i place the google.load("gdata", "1.10"); call within the
GWT onModuleLoad method, then AuthSub stops halfway.
To avoid this we can directly add the following at the top of the GWT
html page:
http://www.google.com/jsapi"</a>;>
google.load("gdata", "1.10");
Or just use the auto-load feature of the JS API to collapse these two
into a single script load.
But this wouldn't make use of the AjaxLoader module and it means that
the GWT app will have to wait for the GData libraries to load before
rendering, etc, instead of doing something like the following:
public void onModuleLoad() {
//render main app here
GData.loadGDataApi(null, new Runnable() {
public void run() {
initialize();
}
});
}
I don't know the reason for this behavior but it could happen if the
gdata library uses document.write for example.
Bobby
On Jul 15, 1:30 am, Bobby wrote:
> I'm adding the GData samples here as i go, if you want to see the
> library in action.http://1.latest.gwt-gdata.appspot.com/v/HelloGData.html
>
> Bobby
>
> On Jul 14, 9:54 am, Eric Ayers wrote:
>
> > Thanks for the update.
>
> > On Mon, Jul 13, 2009 at 11:45 PM, Bobby wrote:
>
> > > Status update: the library is ready, i'm translating the various JS
> > > samples into GWT to include in the first download, using the same
> > > format as the Google Maps sample app which is contained the in the gwt-
> > > maps-1.0.4.zip available here:
> > >http://code.google.com/p/gwt-google-apis/wiki/Downloads?tm=2
>
> > > This is the fun part. :)
>
> > > Bobby
>
> > > On Jun 25, 8:20 am, Thomas Broyer wrote:
> > >> On 25 juin, 08:32, Bobby wrote:
>
> > >> > Actually, i've just noticed that the ArrayHelper in the AjaxLoader
> > >> > module provides the same functionality. Question though, when calling
> > >> > the fromArray() method from within a JSNI method, what's the parameter
> > >> > signature that should be used? I'm not having any luck with fromArray
> > >> > (Lcom/google/gwt/core/client/JavaScriptObject;).
>
> > >> > I want to transform the following:
> > >> > public final native void setProperties(JsArray properties) /
> > >> > *-{
> > >> > this.setProperties(
> > >> > properties
> > >> > );
>
> > >> > }-*/;
>
> > >> > Into the following:
>
> > >> > public final native void setProperties(Property[] properties) /*-{
> > >> > this.setProperties(
> > >> > @net.ltgt.gwt.jscollections.client.JsArrays::fromArray(Lcom/
> > >> > google/gwt/core/client/JavaScriptObject;)(properties)
> > >> > );
>
> > >> > }-*/;
>
> > >> I'd personally use an intermediate setProperty(JsArray) and
> > >> call the fromArray in pure Java.
>
> > >> > But GWT complains about not being able to find the method with that
> > >> > signature.
>
> > >>http://code.google.com/webtoolkit/doc/1.6/DevGuideCodingBasics.html#D...
> > >> links
> > >> tohttp://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/types.html#wp16432
> > >> which says to use:
>
> > >> ...::fromArray([Lcom/google:gwt/core/client/JavaScriptObject;)
> > >> (properties)
>
> > >> (note the left square bracket before the L)
>
> > >> > Also, why are the ellipsis used?
>
> > >> to allow for uses such as fromArray("a", "b", "c") instead of fromArray
> > >> (new String[] { "a", "b", "c" })
>
> > >> > Do they have a special purpose in GWT?
>
> > >> No (and as with generics, it's hardly more than syntactic sugar, as
> > >> the "new String[]" is implied in the example above)
>
> > --
> > Eric Z. Ayers - GWT Team - Atlanta, GA USAhttp://code.google.com/webtoolkit/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
I'm adding the GData samples here as i go, if you want to see the
library in action.
http://1.latest.gwt-gdata.appspot.com/v/HelloGData.html
Bobby
On Jul 14, 9:54 am, Eric Ayers wrote:
> Thanks for the update.
>
>
>
> On Mon, Jul 13, 2009 at 11:45 PM, Bobby wrote:
>
> > Status update: the library is ready, i'm translating the various JS
> > samples into GWT to include in the first download, using the same
> > format as the Google Maps sample app which is contained the in the gwt-
> > maps-1.0.4.zip available here:
> >http://code.google.com/p/gwt-google-apis/wiki/Downloads?tm=2
>
> > This is the fun part. :)
>
> > Bobby
>
> > On Jun 25, 8:20 am, Thomas Broyer wrote:
> >> On 25 juin, 08:32, Bobby wrote:
>
> >> > Actually, i've just noticed that the ArrayHelper in the AjaxLoader
> >> > module provides the same functionality. Question though, when calling
> >> > the fromArray() method from within a JSNI method, what's the parameter
> >> > signature that should be used? I'm not having any luck with fromArray
> >> > (Lcom/google/gwt/core/client/JavaScriptObject;).
>
> >> > I want to transform the following:
> >> > public final native void setProperties(JsArray properties) /
> >> > *-{
> >> > this.setProperties(
> >> > properties
> >> > );
>
> >> > }-*/;
>
> >> > Into the following:
>
> >> > public final native void setProperties(Property[] properties) /*-{
> >> > this.setProperties(
> >> > @net.ltgt.gwt.jscollections.client.JsArrays::fromArray(Lcom/
> >> > google/gwt/core/client/JavaScriptObject;)(properties)
> >> > );
>
> >> > }-*/;
>
> >> I'd personally use an intermediate setProperty(JsArray) and
> >> call the fromArray in pure Java.
>
> >> > But GWT complains about not being able to find the method with that
> >> > signature.
>
> >>http://code.google.com/webtoolkit/doc/1.6/DevGuideCodingBasics.html#D...
> >> links
> >> tohttp://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/types.html#wp16432
> >> which says to use:
>
> >> ...::fromArray([Lcom/google:gwt/core/client/JavaScriptObject;)
> >> (properties)
>
> >> (note the left square bracket before the L)
>
> >> > Also, why are the ellipsis used?
>
> >> to allow for uses such as fromArray("a", "b", "c") instead of fromArray
> >> (new String[] { "a", "b", "c" })
>
> >> > Do they have a special purpose in GWT?
>
> >> No (and as with generics, it's hardly more than syntactic sugar, as
> >> the "new String[]" is implied in the example above)
>
> --
> Eric Z. Ayers - GWT Team - Atlanta, GA USAhttp://code.google.com/webtoolkit/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Status update: the library is ready, i'm translating the various JS
samples into GWT to include in the first download, using the same
format as the Google Maps sample app which is contained the in the gwt-
maps-1.0.4.zip available here:
http://code.google.com/p/gwt-google-apis/wiki/Downloads?tm=2
This is the fun part. :)
Bobby
On Jun 25, 8:20 am, Thomas Broyer wrote:
> On 25 juin, 08:32, Bobby wrote:
>
>
>
> > Actually, i've just noticed that the ArrayHelper in the AjaxLoader
> > module provides the same functionality. Question though, when calling
> > the fromArray() method from within a JSNI method, what's the parameter
> > signature that should be used? I'm not having any luck with fromArray
> > (Lcom/google/gwt/core/client/JavaScriptObject;).
>
> > I want to transform the following:
> > public final native void setProperties(JsArray properties) /
> > *-{
> > this.setProperties(
> > properties
> > );
>
> > }-*/;
>
> > Into the following:
>
> > public final native void setProperties(Property[] properties) /*-{
> > this.setProperties(
> > @net.ltgt.gwt.jscollections.client.JsArrays::fromArray(Lcom/
> > google/gwt/core/client/JavaScriptObject;)(properties)
> > );
>
> > }-*/;
>
> I'd personally use an intermediate setProperty(JsArray) and
> call the fromArray in pure Java.
>
> > But GWT complains about not being able to find the method with that
> > signature.
>
> http://code.google.com/webtoolkit/doc/1.6/DevGuideCodingBasics.html#D...
> links tohttp://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/types.html#wp16432
> which says to use:
>
> ...::fromArray([Lcom/google:gwt/core/client/JavaScriptObject;)
> (properties)
>
> (note the left square bracket before the L)
>
> > Also, why are the ellipsis used?
>
> to allow for uses such as fromArray("a", "b", "c") instead of fromArray
> (new String[] { "a", "b", "c" })
>
> > Do they have a special purpose in GWT?
>
> No (and as with generics, it's hardly more than syntactic sugar, as
> the "new String[]" is implied in the example above)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Actually, i've just noticed that the ArrayHelper in the AjaxLoader
module provides the same functionality. Question though, when calling
the fromArray() method from within a JSNI method, what's the parameter
signature that should be used? I'm not having any luck with fromArray
(Lcom/google/gwt/core/client/JavaScriptObject;).
I want to transform the following:
public final native void setProperties(JsArray properties) /
*-{
this.setProperties(
properties
);
}-*/;
Into the following:
public final native void setProperties(Property[] properties) /*-{
this.setProperties(
@net.ltgt.gwt.jscollections.client.JsArrays::fromArray(Lcom/
google/gwt/core/client/JavaScriptObject;)(properties)
);
}-*/;
But GWT complains about not being able to find the method with that
signature. Also, why are the ellipsis used? Do they have a special
purpose in GWT?
Bobby
On Jun 24, 5:17 am, Thomas Broyer wrote:
> On 24 juin, 05:18, Bobby wrote:
>
> > Nice. Is the JsCollections module your own or are you referencing it
> > externally from somewhere? I'd like to add it via svn:externals.
>
> It is my own, under Apache License 2.0 (same as GWT). You'll find a
> gwt-jscollections.jar in the ZIP from the Downloads tab, containing
> only the JsCollections module. It hasn't changed on SVN since then,
> and it probably won't change unless it has a bug. So I'd rather
> recommend using the JAR instead of svn:externals.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Nice. Is the JsCollections module your own or are you referencing it externally from somewhere? I'd like to add it via svn:externals. Bobby On Jun 23, 5:56 am, Thomas Broyer wrote: > On 22 juin, 23:59, Bobby wrote: > > > 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). > > Little but not negligible: a JsArray has a varying length. > > > 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? > > It would add overhead only in Hosted Mode, as you can use a > "reinterpretCast" in Web Mode with no overhead at all. It's been > discussed several times on the list and you can find an example > (actually, a library) athttp://code.google.com/p/gwt-in-the-air(in > the JsCollections module) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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 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 extends JavaScriptObject
> 2. public class Feed extends
> com.google.gwt.gdata.client.atom.Feed
> 3. public class EventFeed extends
> com.google.gwt.gdata.client.Feed
>
> The remaining Feed classes then extend one of these base Feed classes.
> For example CalendarEventFeed:
> public class CalendarEventFeed extends EventFeed
>
> 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 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 extends
> > JavaScriptObject {
> > ...
>
> > }
>
> > If there are no issues in GWT this should be good.
>
> > Bobby
>
> > On Jun 14, 6:53 pm, Bobby 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 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
> >
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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 extends JavaScriptObject
2. public class Feed extends
com.google.gwt.gdata.client.atom.Feed
3. public class EventFeed extends
com.google.gwt.gdata.client.Feed
The remaining Feed classes then extend one of these base Feed classes.
For example CalendarEventFeed:
public class CalendarEventFeed extends EventFeed
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 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 extends
> JavaScriptObject {
> ...
>
> }
>
> If there are no issues in GWT this should be good.
>
> Bobby
>
> On Jun 14, 6:53 pm, Bobby 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 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 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 structur
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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/calendar/CalendarEventFeed.html
The implementation of the base feed class would look like:
public class Feed extends
JavaScriptObject {
...
}
If there are no issues in GWT this should be good.
Bobby
On Jun 14, 6:53 pm, Bobby 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 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 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.
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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 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 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 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
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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 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 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.
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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 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 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 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 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(), //pas
Re: GWT best Practices - JS Library Wrappers & Overlay Types
In that case i'll leave it as a single module.
The cookie insert approach to getting around authentication ended up
in a little headache because i forgot that GData requires an image to
be present on the page (loaded from the same domain as the page). So,
after forcing the cookie, the jUnit test case was acting as if logged
on but was failing when i called any service, because no image was
present. No error was being thrown in jUnit so i was in the dark for a
while, but after some fiddling i got it. What a relief!
I registered gwt.gd...@gmail.com and successfully got a jUnit test
case to grab events grom GData calendar for that account. Now it's a
matter of doing the same thing for the other services.
Bobby
On Jun 7, 7:20 am, Eric Ayers wrote:
> Sounds like you are making good progress.
>
>
>
> On Sat, Jun 6, 2009 at 10:45 PM, Bobby 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.
>
> In the Gears API, we ran into a similar issue. Should we break out
> the Gears components into separate modules?
>
> In that case we decided that it was a burden on the user to have to
> find and import the correct module. GWT does dead code stripping, so
> there is no penalty at runtime for including parts of the API you
> don't use. We put everything under one com.google.gwt.gears.client
> package in the end.
>
> In the GData case, I could see that developers are less likely to use
> features from across multiple packages, so I could go either way, but
> as far as runtime performance goes, there is no difference either way.
> As far as convenience goes, having everything under one module makes
> the setting up of your project's module easier.
>
>
>
> > Bobby
>
> > On May 30, 10:21 pm, Bobby 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 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 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
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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/google/gwt/accounts
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/google/accounts/client/UserTest.java
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 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 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 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)
> > > at
> > > org.eclipse.swt.internal.ole.win32.IDispatch.Invoke(IDispatch.java:
> > > 64)
> > > at
> > > org.eclipse.swt.ole.win32.OleAutomation.invoke(OleAutomation.java:
> > > 493)
> > > at
> > > org.eclipse.sw
Re: GWT best Practices - JS Library Wrappers & Overlay Types
I eliminated the Date errors by making use of a DateHelper:
http://code.google.com/p/gwt-gdata/source/browse/trunk/gdata/src/com/google/gwt/gdata/client/impl/DateHelper.java
Here's how i'm using it:
http://code.google.com/p/gwt-gdata/source/browse/trunk/gdata/src/com/google/gwt/gdata/client/DateTime.java
I convert Dates to milliseconds since 1970 before passing them between
Java and JS.
Bobby
On May 30, 5:04 pm, Eric Ayers 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 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)
> > at
> > org.eclipse.swt.internal.ole.win32.IDispatch.Invoke(IDispatch.java:
> > 64)
> > at org.eclipse.swt.ole.win32.OleAutomation.invoke(OleAutomation.java:
> > 493)
> > at org.eclipse.swt.ole.win32.OleAutomation.invoke(OleAutomation.java:
> > 417)
> > at com.google.gwt.dev.shell.ie.ModuleSpaceIE6.doInvokeOnWindow
> > (ModuleSpaceIE6.java:67)
> > at com.google.gwt.dev.shell.ie.ModuleSpaceIE6.doInvoke
> > (ModuleSpaceIE6.java:152)
> > at
> > com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:
> > 447)
> > at com.google.gwt.dev.shell.ModuleSpace.invokeNativeVoid
> > (ModuleSpace.java:248)
> > at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeVoid
> > (JavaScriptHost.java:107)
> > at com.google.gwt.gdata.client.app.Edited$.setValue$(Edited.java)
> > at com.google.gwt.gdata.client.app.EditedTest.testProperties
> > (EditedTest.java:42)
> > at
> > com.google.gwt.gdata.client.app.__EditedTest_unitTestImpl.doRunTest
> > (transient source for
> > com.google.gwt.gdata.client.app.__EditedTest_unitTestImpl:7)
> > at junit.framework.TestCase.runTest(TestCase.java:62)
> > at com.google.gwt.junit.client.GWTTestCase.runBare(GWTTestCase.java:
> > 178)
> > at com.google.gwt.junit.client.GWTTestCase.__doRunTest
> > (GWTTestCase.java:116)
> > at com.google.gwt.junit.client.impl.GWTRunner.runTest(GWTRunner.java:
> > 188)
> > at com.google.gwt.junit.client.impl.GWTRunner.doRunTest
> > (GWTRunner.java:163)
> > at
> > com.google.gwt.junit.client.impl.GWTRunner.access$3(GWTRunner.java:
> > 157)
> > at com.google.gwt.junit.client.impl.GWTRunner
> > $JUnitHostListener.onSucce
Re: GWT best Practices - JS Library Wrappers & Overlay Types
ava:2966) at com.google.gwt.dev.GWTShell.pumpEventLoop(GWTShell.java:720) at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:654) at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:150) at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java: 219) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:132) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run (JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run (TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run (RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (RemoteTestRunner.java:196) Any idea why this might be happening? Is it IE6 related? Bobby On May 29, 2:03 am, Bobby wrote: > Thanks that was it. > > Bobby > > On May 26, 9:01 am, Thomas Broyer wrote: > > > > > On 26 mai, 14:56, Eric Ayers wrote: > > > > The read-only link starts with http, but there may be an error in the URL: > > > >http://gwt-google-apis.googlecode.com/svn/trunk/ajaxloader/ajaxloader... > > > > (2 instances of the string ajaxloader in the path) > > > ...and given where Bobby sets his svn:external, it should even > > behttp://gwt-google-apis.googlecode.com/svn/trunk/ajaxloader/ajaxloader...- > > 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 -~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Thanks that was it. Bobby On May 26, 9:01 am, Thomas Broyer wrote: > On 26 mai, 14:56, Eric Ayers wrote: > > > The read-only link starts with http, but there may be an error in the URL: > > >http://gwt-google-apis.googlecode.com/svn/trunk/ajaxloader/ajaxloader... > > > (2 instances of the string ajaxloader in the path) > > ...and given where Bobby sets his svn:external, it should even > behttp://gwt-google-apis.googlecode.com/svn/trunk/ajaxloader/ajaxloader... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
This is the gwt-gdata project http://code.google.com/p/gwt-gdata/. The
code auto-generated from the JS Docs is available:
http://code.google.com/p/gwt-gdata/source/browse/
I uploaded that code mostly for the sake of pointing to it and getting
feedback, there are corrections to be made - though it does compile
and of the unit tests (1 per class) most succeed (187/239) though
these unit tests aren't that involved. It should be a good starting
point.
I still need to plug the ExceptionHelper and ArrayHelper from the
AjaxLoader (have a few questions on this one) into the code and
extract the parameter and return value comments from the JS Docs.
Currently i'm not handling Arrays properly and this came out in the
unit tests. For example in the RecurrenceExceptionEntry (http://
code.google.com/p/gwt-gdata/source/browse/trunk/gdata/src/com/google/
gwt/gdata/client/RecurrenceExceptionEntry.java), the getWhen,
getWhere, getWho, setWhen, setWhere, setWho have return and receive
Java arrays - needs to use JsArray instead (through the
ArrayHelper).
I should probably create a new thread for discussing the GWT-GData
project in specific.
Bobby
On May 25, 11:32 pm, Bobby wrote:
> Eric, what is the svn:externals read-only path for the AjaxLoader
> source? I tried the following with no success (probably because the
> link is not read-only and i don't have checkout access):
>
> ajaxloaderhttp://gwt-google-apis.googlecode.com/svn/trunk/ajaxloader/src/
>
> Bobby
>
> On May 20, 5:21 pm, Bobby wrote:
>
>
>
> > Thanks for the tips Eric.
>
> > - I noticed that newInstance was used in Google Maps so i'm adopted
> > the same convention.
>
> > - I see what you mean about exception handling. I'll make use of your
> > ExceptionHelper for Runnables. For the AsyncCallbacks, i'll try to
> > mirror your ExceptionHelper implementation.
>
> > - When generating the overloads i plug "undefined" in place of omitted
> > optional parameters. Methods with only one parameter were causing the
> > single "undefined" parameter you pointed out, this will be gone after
> > polishing.
>
> > I have another batch of questions/comments coming up - there's one
> > class in GData, the base class for all service classes, which requires
> > some thought since it has methods that may receive constructors (for
> > example GetFeed, which receives the constructor of the feed to be
> > returned). How this class is implemented has some implications on the
> > classes that extend it. I'll have the auto-generated GWT library up
> > sometime next week, this way i'll be able to link to the GWT and JS
> > classes and hopefully get some more feedback on the implementation -
> > not so much on the JSNI code but on the architecture/structure of the
> > library.
>
> > I'm also attempting to auto-generating base Unit tests for each class
> > - most classes are data classes, so Unit tests are straightforward
> > enough (e.g. call each setter, call the corresponding getter, check
> > that the gotten value is the set value). The service classes
> > themselves, which retrieve and update data in the various systems are
> > more difficult, i don't have a plan for those, there will probably be
> > some manual labor but it's not the end of the world if it comes to
> > that.
>
> > Bobby
>
> > On May 18, 3:30 pm, Eric Ayers wrote:
>
> > > Hi Bobby,
>
> > > Thanks for the update, here is some feedback inline. Sorry for the
> > > delay, I was out last week.
>
> > > On Mon, May 11, 2009 at 3:17 AM, Bobby wrote:
>
> > > > I'm very close, i've just compiled a GData JS example via the GData
> > > > GWT library - which retrieves a Calendar feed - and it worked.
>
> > > > Here are some of the implementation choices i've made so far:
> > > > - map all namespaces to be under com.google.gwt.gdata.client.*
> > > > - map all Object parameters to JavaScriptObject (some GData functions
> > > > receive generic JS objects for initialization purposes).
> > > > - implement JS classes as Overlay Types
> > > > - implement class constants as JSNI methods, for example:
> > > > public static native String REL_MESSAGE_TO() /*-{ return
> > > > $wnd.google.gdata.Who.REL_MESSAGE_TO; }-*/;
> > > > - implement constructors as JSNI methods (since i'm using Overlay
> > > > Types), for example:
> > > > public static native Who construct() /*-{ return new
> > > > $wnd.google.gdata.Who(undefined); }-*/;
>
> > > In the gwt-google-apis, I have been nam
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Eric, what is the svn:externals read-only path for the AjaxLoader
source? I tried the following with no success (probably because the
link is not read-only and i don't have checkout access):
ajaxloader http://gwt-google-apis.googlecode.com/svn/trunk/ajaxloader/src/
Bobby
On May 20, 5:21 pm, Bobby wrote:
> Thanks for the tips Eric.
>
> - I noticed that newInstance was used in Google Maps so i'm adopted
> the same convention.
>
> - I see what you mean about exception handling. I'll make use of your
> ExceptionHelper for Runnables. For the AsyncCallbacks, i'll try to
> mirror your ExceptionHelper implementation.
>
> - When generating the overloads i plug "undefined" in place of omitted
> optional parameters. Methods with only one parameter were causing the
> single "undefined" parameter you pointed out, this will be gone after
> polishing.
>
> I have another batch of questions/comments coming up - there's one
> class in GData, the base class for all service classes, which requires
> some thought since it has methods that may receive constructors (for
> example GetFeed, which receives the constructor of the feed to be
> returned). How this class is implemented has some implications on the
> classes that extend it. I'll have the auto-generated GWT library up
> sometime next week, this way i'll be able to link to the GWT and JS
> classes and hopefully get some more feedback on the implementation -
> not so much on the JSNI code but on the architecture/structure of the
> library.
>
> I'm also attempting to auto-generating base Unit tests for each class
> - most classes are data classes, so Unit tests are straightforward
> enough (e.g. call each setter, call the corresponding getter, check
> that the gotten value is the set value). The service classes
> themselves, which retrieve and update data in the various systems are
> more difficult, i don't have a plan for those, there will probably be
> some manual labor but it's not the end of the world if it comes to
> that.
>
> Bobby
>
> On May 18, 3:30 pm, Eric Ayers wrote:
>
>
>
> > Hi Bobby,
>
> > Thanks for the update, here is some feedback inline. Sorry for the
> > delay, I was out last week.
>
> > On Mon, May 11, 2009 at 3:17 AM, Bobby wrote:
>
> > > I'm very close, i've just compiled a GData JS example via the GData
> > > GWT library - which retrieves a Calendar feed - and it worked.
>
> > > Here are some of the implementation choices i've made so far:
> > > - map all namespaces to be under com.google.gwt.gdata.client.*
> > > - map all Object parameters to JavaScriptObject (some GData functions
> > > receive generic JS objects for initialization purposes).
> > > - implement JS classes as Overlay Types
> > > - implement class constants as JSNI methods, for example:
> > > public static native String REL_MESSAGE_TO() /*-{ return
> > > $wnd.google.gdata.Who.REL_MESSAGE_TO; }-*/;
> > > - implement constructors as JSNI methods (since i'm using Overlay
> > > Types), for example:
> > > public static native Who construct() /*-{ return new
> > > $wnd.google.gdata.Who(undefined); }-*/;
>
> > In the gwt-google-apis, I have been naming these factory methods
> > newInstance() or getInstance() for constructing singletons. This
> > comes from convention in the JRE and Joshua Bloch's "Effective Java".
>
> > > - generate overloads for methods that have optional parameters or
> > > multi-type parameters in JS, for example:
> > > public final native void setValueString(String valueString) /*-
> > > { this.setValueString(valueString); }-*/;
> > > public final native void setValueString() /*-{ this.setValueString
> > > (undefined); }-*/;
> > > - implement continuation callbacks (non success/failure) as Runnable,
> > > for example:
> > > public static final native boolean getInfo(Runnable callback) /*-
> > > { return $wnd.google.accounts.user.getInfo(function()
> > > { callba...@java.lang.runnable::run()(); }); }-*/;
>
> > This is good, but in order to display exceptions in Hosted mode, a
> > more complex pattern is needed. Essentially, you need to call a
> > special handler for exceptions in hosted mode. A particularly nice
> > implementation of this is the Handler class in gwt-visualization which
> > uses the ExceptionHelper class in the ajaxloader package.
>
> >http://code.google.com/p/gwt-google-apis/source/browse/releases/visua..
>
> > I usually pull the ajaxloader class into the other gwt-google-ap
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Thanks for the tips Eric.
- I noticed that newInstance was used in Google Maps so i'm adopted
the same convention.
- I see what you mean about exception handling. I'll make use of your
ExceptionHelper for Runnables. For the AsyncCallbacks, i'll try to
mirror your ExceptionHelper implementation.
- When generating the overloads i plug "undefined" in place of omitted
optional parameters. Methods with only one parameter were causing the
single "undefined" parameter you pointed out, this will be gone after
polishing.
I have another batch of questions/comments coming up - there's one
class in GData, the base class for all service classes, which requires
some thought since it has methods that may receive constructors (for
example GetFeed, which receives the constructor of the feed to be
returned). How this class is implemented has some implications on the
classes that extend it. I'll have the auto-generated GWT library up
sometime next week, this way i'll be able to link to the GWT and JS
classes and hopefully get some more feedback on the implementation -
not so much on the JSNI code but on the architecture/structure of the
library.
I'm also attempting to auto-generating base Unit tests for each class
- most classes are data classes, so Unit tests are straightforward
enough (e.g. call each setter, call the corresponding getter, check
that the gotten value is the set value). The service classes
themselves, which retrieve and update data in the various systems are
more difficult, i don't have a plan for those, there will probably be
some manual labor but it's not the end of the world if it comes to
that.
Bobby
On May 18, 3:30 pm, Eric Ayers wrote:
> Hi Bobby,
>
> Thanks for the update, here is some feedback inline. Sorry for the
> delay, I was out last week.
>
>
>
>
>
> On Mon, May 11, 2009 at 3:17 AM, Bobby wrote:
>
> > I'm very close, i've just compiled a GData JS example via the GData
> > GWT library - which retrieves a Calendar feed - and it worked.
>
> > Here are some of the implementation choices i've made so far:
> > - map all namespaces to be under com.google.gwt.gdata.client.*
> > - map all Object parameters to JavaScriptObject (some GData functions
> > receive generic JS objects for initialization purposes).
> > - implement JS classes as Overlay Types
> > - implement class constants as JSNI methods, for example:
> > public static native String REL_MESSAGE_TO() /*-{ return
> > $wnd.google.gdata.Who.REL_MESSAGE_TO; }-*/;
> > - implement constructors as JSNI methods (since i'm using Overlay
> > Types), for example:
> > public static native Who construct() /*-{ return new
> > $wnd.google.gdata.Who(undefined); }-*/;
>
> In the gwt-google-apis, I have been naming these factory methods
> newInstance() or getInstance() for constructing singletons. This
> comes from convention in the JRE and Joshua Bloch's "Effective Java".
>
> > - generate overloads for methods that have optional parameters or
> > multi-type parameters in JS, for example:
> > public final native void setValueString(String valueString) /*-
> > { this.setValueString(valueString); }-*/;
> > public final native void setValueString() /*-{ this.setValueString
> > (undefined); }-*/;
> > - implement continuation callbacks (non success/failure) as Runnable,
> > for example:
> > public static final native boolean getInfo(Runnable callback) /*-
> > { return $wnd.google.accounts.user.getInfo(function()
> > { callba...@java.lang.runnable::run()(); }); }-*/;
>
> This is good, but in order to display exceptions in Hosted mode, a
> more complex pattern is needed. Essentially, you need to call a
> special handler for exceptions in hosted mode. A particularly nice
> implementation of this is the Handler class in gwt-visualization which
> uses the ExceptionHelper class in the ajaxloader package.
>
> http://code.google.com/p/gwt-google-apis/source/browse/releases/visua...http://code.google.com/p/gwt-google-apis/source/browse/releases/ajaxl...
>
> I usually pull the ajaxloader class into the other gwt-google-api
> projects using an svn:externals property if you haven't done that
> already.
>
> > - implement success/failure callbacks as AsyncCallback, for
> > example:
> > public final native CalendarAclFeed getAclFeed(String uri,
> > AsyncCallback callback) /*-{
> > return this.getAclFeed(uri, function(result)
> > { @com.google.gwt.gdata.client.impl.Utils::handleSuccessCallback(Lcom/
> > google/gwt/user/client/rpc/AsyncCallback;Ljava/lang/Object;)(callback,
> > result); }, function(error)
> > { @com.google.gwt.gdata.client.impl.Utils::handleFailure
Re: GWT best Practices - JS Library Wrappers & Overlay Types
ndeeStatus(attendeeStatus); }-*/;
public final native void setAttendeeType(JavaScriptObject
attendeeType) /*-{ this.setAttendeeType(attendeeType); }-*/;
public final native void setAttendeeType() /*-{ this.setAttendeeType
(undefined); }-*/;
public final native void setAttendeeType(AttendeeType attendeeType) /
*-{ this.setAttendeeType(attendeeType); }-*/;
public final native void setEmail(String email) /*-{ this.setEmail
(email); }-*/;
public final native void setEmail() /*-{ this.setEmail(undefined); }-
*/;
public final native void setEntryLink(JavaScriptObject entryLink) /*-
{ this.setEntryLink(entryLink); }-*/;
public final native void setEntryLink() /*-{ this.setEntryLink
(undefined); }-*/;
public final native void setEntryLink(EntryLink entryLink) /*-
{ this.setEntryLink(entryLink); }-*/;
public final native void setRel(String rel) /*-{ this.setRel(rel); }-
*/;
public final native void setRel() /*-{ this.setRel(undefined); }-*/;
public final native void setValueString(String valueString) /*-
{ this.setValueString(valueString); }-*/;
public final native void setValueString() /*-{ this.setValueString
(undefined); }-*/;
}
Bobby
On May 3, 9:05 pm, Eric Ayers wrote:
> I think you should make it a separate module, but at this point, I think it
> should remain under gdata for now. I see other APIs use this namespace, but
> I will have to coordinate to see if it can truly be shared like AjaxLoader
> apis.
>
>
>
>
>
> On Sun, May 3, 2009 at 2:51 PM, Bobby wrote:
>
> > Thanks Eric, it works for me. On a related topic, there's a namespace
> > in the GData API, google.accounts, that i think should be in its own
> > GWT module as well:
> >http://code.google.com/apis/gdata/jsdoc/1.8/google/accounts.html
>
> > It's used by GData to authenticate via AuthSub, but it's outside
> > GData.
>
> > Bobby
>
> > On May 3, 6:38 am, Eric Ayers wrote:
> > > Hi guys,
> > > The AjaxLoader API will be put in public release soon. I've made a
> > release
> > > branch for it under subversion athttp://
> > gwt-google-apis.googlecode.com/svn/releases/ajaxloader/1.0
>
> > > -Eric.
>
> > > On Sun, May 3, 2009 at 2:40 AM, Bobby wrote:
>
> > > > I'm going over the following pages carefully:
>
> > > >http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis.
> > ..
>
> > > > Some GWT APIs, such as the Maps API, already have an implementation of
> > > > the AjaxLoader for loading Google JS libraries, so that's one less
> > > > thing to do.
>
> > > > Bobby
>
> > > > On Apr 27, 2:58 am, Bobby wrote:
> > > > > I just came across some interesting docs, this one in particular
> > > > > covers almost all the questions i had in my original post (lots of
> > > > > TBDs though):
> > > >http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis.
> > ..
>
> > > > > Also, check out what's underneath the "large efforts" heading in the
> > > > > wishlist page:
> > > >http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis.
> > ..
>
> > > > > That's right, and here i am going it alone, you ought to be
> > > > > ashamed. :)
>
> > > > > Bobby
>
> > > > > On Apr 27, 2:21 am, Bobby wrote:
>
> > > > > > I would prefer having a GWT library for GData, it seems within
> > reach.
>
> > > > > > Bobby
>
> > > > > > On Apr 26, 11:55 pm, Vitali Lovich wrote:
>
> > > > > > > Couldn't arbitrary JS support be added using deferred binding?
> > Sure,
> > > > you
> > > > > > > wouldn't be able to do code completion, but you could call
> > arbitrary
> > > > JS
> > > > > > > functions & variables with 0-overhead. Might be a cool project
> > to do
> > > > (if
> > > > > > > Ray hasn't already done it :D).
>
> > > > > > > On Sun, Apr 26, 2009 at 11:43 PM, Bobby
> > > > wrote:
>
> > > > > > > > I finally got the GData library to compile inside a GWT 1.6
> > test
> > > > app.
> > > > > > > > Now it's down to testing.
>
> > > > > > > > I'm considering auto generating a test app as well, otherwise i
> > > > won't
> > > > > > > > be able to find out w
GetParent() Calls to a Composite type
I have the following situation:
class WidgetA extends Composite {
public WidgetA() {
initWidget(new VerticalPanel());
}
public void add(Widget w) {
((VerticalPanel) getWidget()).add(w);
}
}
And somewhere else I make a call like:
WidgetA a = new WidgetA();
WidgetB b = new WidgetB();
a.add(b);
Later on I need to get the WidgetA object that WidgetB belongs to (was
added to), so naturally I think to call b.getParent(). However, this
will return a VerticalPanel.
I can't come up with a good generic way of being able to return the
corresponding WidgetA object for any Widget that may be added to it
(not just type WidgetB). Any suggestions?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Thanks Eric, it works for me. On a related topic, there's a namespace in the GData API, google.accounts, that i think should be in its own GWT module as well: http://code.google.com/apis/gdata/jsdoc/1.8/google/accounts.html It's used by GData to authenticate via AuthSub, but it's outside GData. Bobby On May 3, 6:38 am, Eric Ayers wrote: > Hi guys, > The AjaxLoader API will be put in public release soon. I've made a release > branch for it under subversion > athttp://gwt-google-apis.googlecode.com/svn/releases/ajaxloader/1.0 > > -Eric. > > > > > > On Sun, May 3, 2009 at 2:40 AM, Bobby wrote: > > > I'm going over the following pages carefully: > > >http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis... > > > Some GWT APIs, such as the Maps API, already have an implementation of > > the AjaxLoader for loading Google JS libraries, so that's one less > > thing to do. > > > Bobby > > > On Apr 27, 2:58 am, Bobby wrote: > > > I just came across some interesting docs, this one in particular > > > covers almost all the questions i had in my original post (lots of > > > TBDs though): > >http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis... > > > > Also, check out what's underneath the "large efforts" heading in the > > > wishlist page: > >http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis... > > > > That's right, and here i am going it alone, you ought to be > > > ashamed. :) > > > > Bobby > > > > On Apr 27, 2:21 am, Bobby wrote: > > > > > I would prefer having a GWT library for GData, it seems within reach. > > > > > Bobby > > > > > On Apr 26, 11:55 pm, Vitali Lovich wrote: > > > > > > Couldn't arbitrary JS support be added using deferred binding? Sure, > > you > > > > > wouldn't be able to do code completion, but you could call arbitrary > > JS > > > > > functions & variables with 0-overhead. Might be a cool project to do > > (if > > > > > Ray hasn't already done it :D). > > > > > > On Sun, Apr 26, 2009 at 11:43 PM, Bobby > > wrote: > > > > > > > I finally got the GData library to compile inside a GWT 1.6 test > > app. > > > > > > Now it's down to testing. > > > > > > > I'm considering auto generating a test app as well, otherwise i > > won't > > > > > > be able to find out what's broken, otherwise i have to test each > > class > > > > > > manually. > > > > > > > It looks good at this point but i'm antecipating plenty of > > headaches > > > > > > in testing. > > > > > > > Bobby > > > > > > > On Apr 20, 6:51 pm, Bobby wrote: > > > > > > > The GData JS API is doing some fancy stuff to be able to POST > > data > > > > > > > across domains, etc, it's also fairly large (in number of > > classes) and > > > > > > > it's missing some large GData components (for Google Docs and > > > > > > > Spreadsheets). All of this i'm guessing is why Google doesn't > > have a > > > > > > > GWT library out for GData yet. I wouldn't want to code this > > manually > > > > > > > but i if i can automate it then it's ok. > > > > > > > > > I'd rather wait to see some code ;-) > > > > > > > > (and I have so many projects yet that I don't have time to > > update...) > > > > > > > > Oh right, no chance, it's now or never (or whenever you feel like > > up > > > > > > > to it, just let me know). > > > > > > > > I'm counting on being able to auto-generate a decent wrapper > > without > > > > > > > much difficulty, if this becomes complex or beyond my means i'll > > just > > > > > > > let Google worry about it. This is why i want to test a rough > > version > > > > > > > of the wrapper ASAP. > > > > > > > > Anyway thanks for all the pointers, i'll post more questions here > > as > > > > > > > they come up. > > > > > > > > Bobby > > > > > > > > On Apr 20, 6:04 pm, Thomas Broyer wrote: > > > > > > > &
Re: GWT best Practices - JS Library Wrappers & Overlay Types
I'm going over the following pages carefully: http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis&t=Overview Some GWT APIs, such as the Maps API, already have an implementation of the AjaxLoader for loading Google JS libraries, so that's one less thing to do. Bobby On Apr 27, 2:58 am, Bobby wrote: > I just came across some interesting docs, this one in particular > covers almost all the questions i had in my original post (lots of > TBDs > though):http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis... > > Also, check out what's underneath the "large efforts" heading in the > wishlist > page:http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis... > > That's right, and here i am going it alone, you ought to be > ashamed. :) > > Bobby > > On Apr 27, 2:21 am, Bobby wrote: > > > > > I would prefer having a GWT library for GData, it seems within reach. > > > Bobby > > > On Apr 26, 11:55 pm, Vitali Lovich wrote: > > > > Couldn't arbitrary JS support be added using deferred binding? Sure, you > > > wouldn't be able to do code completion, but you could call arbitrary JS > > > functions & variables with 0-overhead. Might be a cool project to do (if > > > Ray hasn't already done it :D). > > > > On Sun, Apr 26, 2009 at 11:43 PM, Bobby wrote: > > > > > I finally got the GData library to compile inside a GWT 1.6 test app. > > > > Now it's down to testing. > > > > > I'm considering auto generating a test app as well, otherwise i won't > > > > be able to find out what's broken, otherwise i have to test each class > > > > manually. > > > > > It looks good at this point but i'm antecipating plenty of headaches > > > > in testing. > > > > > Bobby > > > > > On Apr 20, 6:51 pm, Bobby wrote: > > > > > The GData JS API is doing some fancy stuff to be able to POST data > > > > > across domains, etc, it's also fairly large (in number of classes) and > > > > > it's missing some large GData components (for Google Docs and > > > > > Spreadsheets). All of this i'm guessing is why Google doesn't have a > > > > > GWT library out for GData yet. I wouldn't want to code this manually > > > > > but i if i can automate it then it's ok. > > > > > > > I'd rather wait to see some code ;-) > > > > > > (and I have so many projects yet that I don't have time to > > > > > > update...) > > > > > > Oh right, no chance, it's now or never (or whenever you feel like up > > > > > to it, just let me know). > > > > > > I'm counting on being able to auto-generate a decent wrapper without > > > > > much difficulty, if this becomes complex or beyond my means i'll just > > > > > let Google worry about it. This is why i want to test a rough version > > > > > of the wrapper ASAP. > > > > > > Anyway thanks for all the pointers, i'll post more questions here as > > > > > they come up. > > > > > > Bobby > > > > > > On Apr 20, 6:04 pm, Thomas Broyer wrote: > > > > > > > On Mon, Apr 20, 2009 at 6:38 PM, Bobby wrote: > > > > > > > > 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. > > > > > > > Given that the protocol is clearly defined and documented, I wonder > > > > > > if > > > > > > a "pure GWT" implementation wouldn't be better... > > > > > > Well, eventually, that could be your "v2.0" ;-) > > > > > > > > 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( > > > >
Re: GWT best Practices - JS Library Wrappers & Overlay Types
I just came across some interesting docs, this one in particular covers almost all the questions i had in my original post (lots of TBDs though): http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis&t=DesigningAPIWrappers Also, check out what's underneath the "large efforts" heading in the wishlist page: http://code.google.com/docreader/#p=gwt-google-apis&s=gwt-google-apis&t=WishList That's right, and here i am going it alone, you ought to be ashamed. :) Bobby On Apr 27, 2:21 am, Bobby wrote: > I would prefer having a GWT library for GData, it seems within reach. > > Bobby > > On Apr 26, 11:55 pm, Vitali Lovich wrote: > > > > > Couldn't arbitrary JS support be added using deferred binding? Sure, you > > wouldn't be able to do code completion, but you could call arbitrary JS > > functions & variables with 0-overhead. Might be a cool project to do (if > > Ray hasn't already done it :D). > > > On Sun, Apr 26, 2009 at 11:43 PM, Bobby wrote: > > > > I finally got the GData library to compile inside a GWT 1.6 test app. > > > Now it's down to testing. > > > > I'm considering auto generating a test app as well, otherwise i won't > > > be able to find out what's broken, otherwise i have to test each class > > > manually. > > > > It looks good at this point but i'm antecipating plenty of headaches > > > in testing. > > > > Bobby > > > > On Apr 20, 6:51 pm, Bobby wrote: > > > > The GData JS API is doing some fancy stuff to be able to POST data > > > > across domains, etc, it's also fairly large (in number of classes) and > > > > it's missing some large GData components (for Google Docs and > > > > Spreadsheets). All of this i'm guessing is why Google doesn't have a > > > > GWT library out for GData yet. I wouldn't want to code this manually > > > > but i if i can automate it then it's ok. > > > > > > I'd rather wait to see some code ;-) > > > > > (and I have so many projects yet that I don't have time to update...) > > > > > Oh right, no chance, it's now or never (or whenever you feel like up > > > > to it, just let me know). > > > > > I'm counting on being able to auto-generate a decent wrapper without > > > > much difficulty, if this becomes complex or beyond my means i'll just > > > > let Google worry about it. This is why i want to test a rough version > > > > of the wrapper ASAP. > > > > > Anyway thanks for all the pointers, i'll post more questions here as > > > > they come up. > > > > > Bobby > > > > > On Apr 20, 6:04 pm, Thomas Broyer wrote: > > > > > > On Mon, Apr 20, 2009 at 6:38 PM, Bobby wrote: > > > > > > > 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. > > > > > > Given that the protocol is clearly defined and documented, I wonder if > > > > > a "pure GWT" implementation wouldn't be better... > > > > > Well, eventually, that could be your "v2.0" ;-) > > > > > > > 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( continuation, > > > > > > opt_errorHandler). > > > > > > Er, you probably mean void updateEntry( > > > > function(google.gdata.Entry)> continuation, > > > > > 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). > > > > > > Well, I don't know what you're generating from, but it could be as > > > > > easy as "if the method takes 2 arguments of type fu
Re: GWT best Practices - JS Library Wrappers & Overlay Types
I would prefer having a GWT library for GData, it seems within reach. Bobby On Apr 26, 11:55 pm, Vitali Lovich wrote: > Couldn't arbitrary JS support be added using deferred binding? Sure, you > wouldn't be able to do code completion, but you could call arbitrary JS > functions & variables with 0-overhead. Might be a cool project to do (if > Ray hasn't already done it :D). > > > > On Sun, Apr 26, 2009 at 11:43 PM, Bobby wrote: > > > I finally got the GData library to compile inside a GWT 1.6 test app. > > Now it's down to testing. > > > I'm considering auto generating a test app as well, otherwise i won't > > be able to find out what's broken, otherwise i have to test each class > > manually. > > > It looks good at this point but i'm antecipating plenty of headaches > > in testing. > > > Bobby > > > On Apr 20, 6:51 pm, Bobby wrote: > > > The GData JS API is doing some fancy stuff to be able to POST data > > > across domains, etc, it's also fairly large (in number of classes) and > > > it's missing some large GData components (for Google Docs and > > > Spreadsheets). All of this i'm guessing is why Google doesn't have a > > > GWT library out for GData yet. I wouldn't want to code this manually > > > but i if i can automate it then it's ok. > > > > > I'd rather wait to see some code ;-) > > > > (and I have so many projects yet that I don't have time to update...) > > > > Oh right, no chance, it's now or never (or whenever you feel like up > > > to it, just let me know). > > > > I'm counting on being able to auto-generate a decent wrapper without > > > much difficulty, if this becomes complex or beyond my means i'll just > > > let Google worry about it. This is why i want to test a rough version > > > of the wrapper ASAP. > > > > Anyway thanks for all the pointers, i'll post more questions here as > > > they come up. > > > > Bobby > > > > On Apr 20, 6:04 pm, Thomas Broyer wrote: > > > > > On Mon, Apr 20, 2009 at 6:38 PM, Bobby wrote: > > > > > > 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. > > > > > Given that the protocol is clearly defined and documented, I wonder if > > > > a "pure GWT" implementation wouldn't be better... > > > > Well, eventually, that could be your "v2.0" ;-) > > > > > > 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( continuation, > > > > > opt_errorHandler). > > > > > Er, you probably mean void updateEntry( > > > function(google.gdata.Entry)> continuation, > > > > 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). > > > > > Well, I don't know what you're generating from, but it could be as > > > > easy as "if the method takes 2 arguments of type function, the second > > > > one taking an Error argument, then convert them to an AsyncCallback > > > > where T is the method's documented return type, and make the method > > > > actually have a void return type". > > > > > > 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. > > > > > Hmm, not quite sure what you're talking about... > > > > > > 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. > >
Re: GWT best Practices - JS Library Wrappers & Overlay Types
I finally got the GData library to compile inside a GWT 1.6 test app. Now it's down to testing. I'm considering auto generating a test app as well, otherwise i won't be able to find out what's broken, otherwise i have to test each class manually. It looks good at this point but i'm antecipating plenty of headaches in testing. Bobby On Apr 20, 6:51 pm, Bobby wrote: > The GData JS API is doing some fancy stuff to be able to POST data > across domains, etc, it's also fairly large (in number of classes) and > it's missing some large GData components (for Google Docs and > Spreadsheets). All of this i'm guessing is why Google doesn't have a > GWT library out for GData yet. I wouldn't want to code this manually > but i if i can automate it then it's ok. > > > I'd rather wait to see some code ;-) > > (and I have so many projects yet that I don't have time to update...) > > Oh right, no chance, it's now or never (or whenever you feel like up > to it, just let me know). > > I'm counting on being able to auto-generate a decent wrapper without > much difficulty, if this becomes complex or beyond my means i'll just > let Google worry about it. This is why i want to test a rough version > of the wrapper ASAP. > > Anyway thanks for all the pointers, i'll post more questions here as > they come up. > > Bobby > > On Apr 20, 6:04 pm, Thomas Broyer wrote: > > > > > On Mon, Apr 20, 2009 at 6:38 PM, Bobby wrote: > > > > 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. > > > Given that the protocol is clearly defined and documented, I wonder if > > a "pure GWT" implementation wouldn't be better... > > Well, eventually, that could be your "v2.0" ;-) > > > > 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( continuation, > > > opt_errorHandler). > > > Er, you probably mean void updateEntry( > function(google.gdata.Entry)> continuation, > > 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). > > > Well, I don't know what you're generating from, but it could be as > > easy as "if the method takes 2 arguments of type function, the second > > one taking an Error argument, then convert them to an AsyncCallback > > where T is the method's documented return type, and make the method > > actually have a void return type". > > > > 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. > > > Hmm, not quite sure what you're talking about... > > > > 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. > > > I'd rather wait to see some code ;-) > > (and I have so many projects yet that I don't have time to update...) > > > > 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. > > > Probably because they'd rather do it in GWT than as a GWT wrapper > > around the JS API, which is a bit more work probably... > > (and they'd have to have time to maintain it, etc.) > > > Anyway, good luck ;-) > > > -- > > Thomas Broyer- 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 -~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
The GData JS API is doing some fancy stuff to be able to POST data across domains, etc, it's also fairly large (in number of classes) and it's missing some large GData components (for Google Docs and Spreadsheets). All of this i'm guessing is why Google doesn't have a GWT library out for GData yet. I wouldn't want to code this manually but i if i can automate it then it's ok. > I'd rather wait to see some code ;-) > (and I have so many projects yet that I don't have time to update...) Oh right, no chance, it's now or never (or whenever you feel like up to it, just let me know). I'm counting on being able to auto-generate a decent wrapper without much difficulty, if this becomes complex or beyond my means i'll just let Google worry about it. This is why i want to test a rough version of the wrapper ASAP. Anyway thanks for all the pointers, i'll post more questions here as they come up. Bobby On Apr 20, 6:04 pm, Thomas Broyer wrote: > On Mon, Apr 20, 2009 at 6:38 PM, Bobby wrote: > > > 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. > > Given that the protocol is clearly defined and documented, I wonder if > a "pure GWT" implementation wouldn't be better... > Well, eventually, that could be your "v2.0" ;-) > > > 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( continuation, > > opt_errorHandler). > > Er, you probably mean void updateEntry( function(google.gdata.Entry)> continuation, > 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). > > Well, I don't know what you're generating from, but it could be as > easy as "if the method takes 2 arguments of type function, the second > one taking an Error argument, then convert them to an AsyncCallback > where T is the method's documented return type, and make the method > actually have a void return type". > > > 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. > > Hmm, not quite sure what you're talking about... > > > 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. > > I'd rather wait to see some code ;-) > (and I have so many projects yet that I don't have time to update...) > > > 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. > > Probably because they'd rather do it in GWT than as a GWT wrapper > around the JS API, which is a bit more work probably... > (and they'd have to have time to maintain it, etc.) > > Anyway, good luck ;-) > > -- > Thomas Broyer --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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( continuation,
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 wrote:
> On 20 avr, 03:56, Bobby 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( continuation,
> > opt_errorHandler)
>
> > Java
> > public final native Entry getSelf( continuation,
> > opt_errorHandler)/*-{
> > //it gets difficult here
> > var cbw1 = { cb: co
Re: GWT best Practices - JS Library Wrappers & Overlay Types
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( continuation,
opt_errorHandler)
Java
public final native Entry getSelf( continuation,
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 wrote:
> On 20 avr, 01:47, Bobby 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 f
Re: GWT best Practices - JS Library Wrappers & Overlay Types
Thomas, thanks for the reply that's what i wanted to hear for
questions 1, 2, 3 and 4.
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.
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
(); }-*/;
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); }-*/;
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); }
private static native String getConstantValue(String name) /*-
{ return google.gdata.Im[name]; }-*/;
}
}
[/code]
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.
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?). 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%.
Bobby
On Apr 19, 7:07 pm, Thomas Broyer wrote:
> On 18 avr, 22:24, Bobby wrote:
>
> > I'm in the process of trying to dynamically generate a GWT wrapper for
> > an existing JS library and i have a few questions which come down to
> > best practices for the most part.
>
> > 1. When wrapping a JS library with GWT, is it recommended to leave the
> > namespaces intact? If the JS library and the GWT wrapper library have
> > the same namespaces, is there a chance of a conflict where GWT code
> > will overwrite the original namespaces of the JS library? (i don't
> > think this is the case but i wanted to verify)
>
> There's no notion of "namespaces" in the Javascript code resulting
> from GWT compilation (actually, there's no notion of "namespaces" in
> JavaScript either, at all, but that's just a problem of vocabulary).
> Even when compiling in -style PRETTY or DETAILED, GWT shouldn't
> override/shadow any JavaScript variable defined outside the GWT code
> (everything's initialized in a closure to not polute the global scope,
> and in JSNI you should use $wnd.XXX to access a variable called XXX
> defined in the global namespace, so...)
>
> > 2. If the JS library that's being wrapped around has classes that may
> > need
Re: GWT best Practices - JS Library Wrappers & Overlay Types
One more for the list:
6. When the original JS library contains one or more classes with
methods that receive functions as parameters, what is the best way to
implement these methods? Should there be a generic Function or
Callback class on the GWT side that is used as the function parameter
type? The function that is passed to the JS method may expect to
receive a different number of parameters itself, so one option is to
define the following class in Java:
public class GenericCallback(){
public void Execute(Object[] Parameters){
...
}
}
With this approach the following JavaScript method:
function doSomething(myCallback){}
Would be translated to the following in GWT:
public final native void doSomething(GenericCallback myCallback)/*-{
var cb = function(a, b, c, d, e){
var pars = [a,b,c,d,e];//something fancier than this
var jcb = this.handler;
@jcb.GenericCallback::Execute([Ljava/lang/Object;)(pars);
}
cb.handler = myCallback;//or something like this that actually
works
this.doSomething(cb);
}-*/
I don't like the idea of joining all the parameters in an array or of
having a function in Java receive an object array, but otherwise there
would need to be multiple Execute methods with a different number of
parameters or even multiple Callback classes in Java, each with its
own particular Execute method. This wouldn't be so difficult if i was
generating the code manually.
Here's a concrete example of what i'm talking about:
http://code.google.com/apis/gdata/jsdoc/1.8/google/gdata/Entry.html
This class has methods that receive function callbacks (for example
deleteEntry). If you were trying to auto generate a GWT wrapper for
that class how would you handle the methods that receive Function
parameters? (assuming that we're using Overlay Types for the
wrapping).
Bobby
On Apr 18, 4:24 pm, Bobby wrote:
> I'm in the process of trying to dynamically generate a GWT wrapper for
> an existing JS library and i have a few questions which come down to
> best practices for the most part.
>
> 1. When wrapping a JS library with GWT, is it recommended to leave the
> namespaces intact? If the JS library and the GWT wrapper library have
> the same namespaces, is there a chance of a conflict where GWT code
> will overwrite the original namespaces of the JS library? (i don't
> think this is the case but i wanted to verify)
>
> 2. If the JS library that's being wrapped around has classes that may
> need to be constructed from the Java side, then are Overlay Types
> automatically out of the question (in which case plain Java wrapper
> classes would be used) or is it better to still use Overlay Types and
> just expose factory methods for doing the job of the constructors?
>
> 3. If the original JS library has classes where fields are commonly
> accessed directly, as opposed to via getters and setters, then is it
> recommended to remain faithful to the original JS library and expose
> the fields without getters/setters (in which case Overlay Types are
> out of the picture) or ignore this aspect of the original JS library
> and expose getters/setters instead.
>
> 4. If the original JS library has a method that has optional
> parameters, for example, myFunc(a, b) where b may be undefined, should
> a single Java method be added, or should multiple overloaded methods
> be used? For example:
> myFunc(a)
> myFunc(a, b)
>
> 5. Should constants be automatically converted to enumerations or
> should they just be left alone?
>
> If you have some insight on these questions (or any others i missed) i
> would really welcome your input.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
GWT best Practices - JS Library Wrappers & Overlay Types
I'm in the process of trying to dynamically generate a GWT wrapper for an existing JS library and i have a few questions which come down to best practices for the most part. 1. When wrapping a JS library with GWT, is it recommended to leave the namespaces intact? If the JS library and the GWT wrapper library have the same namespaces, is there a chance of a conflict where GWT code will overwrite the original namespaces of the JS library? (i don't think this is the case but i wanted to verify) 2. If the JS library that's being wrapped around has classes that may need to be constructed from the Java side, then are Overlay Types automatically out of the question (in which case plain Java wrapper classes would be used) or is it better to still use Overlay Types and just expose factory methods for doing the job of the constructors? 3. If the original JS library has classes where fields are commonly accessed directly, as opposed to via getters and setters, then is it recommended to remain faithful to the original JS library and expose the fields without getters/setters (in which case Overlay Types are out of the picture) or ignore this aspect of the original JS library and expose getters/setters instead. 4. If the original JS library has a method that has optional parameters, for example, myFunc(a, b) where b may be undefined, should a single Java method be added, or should multiple overloaded methods be used? For example: myFunc(a) myFunc(a, b) 5. Should constants be automatically converted to enumerations or should they just be left alone? If you have some insight on these questions (or any others i missed) i would really welcome your input. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Wrapping Around GData JS API With GWT
Thanks Sumit, that's what i wanted to hear. I've added a project for the GData-GWT library: http://code.google.com/p/gdata-gwt-client/ Also, i managed to scrape the information in the JS Docs for GData (http://code.google.com/apis/gdata/jsdoc/1.8/index.html) so i'm looking to dynamically generate the GWT libraries using the overlay technique that you described - this way, i can easily keep it in sync with the GData JS library. If anyone reading this thread is interested in contributing to this project just let me know. Bobby On Apr 13, 5:37 pm, Sumit Chandel wrote: > Hi Bobby, > Please check out replies inlined below: > > 1. I couldn't find a GData Library for GWT, did i miss it (i already > > > checked with the GData group)? I know GData has the Java API, but that > > (probably) won't compile to JavaScript. However, GData also has a JS > > API (the JS docs are here > >http://code.google.com/apis/gdata/jsdoc/1.8/index.html), > > so at a minimum we could wrap the JS API in a very thin GWT library - > > i'm wondering if this already exists or if it's planned as an addition > > to the list of GWT Google API Libraries (http://code.google.com/ > > webtoolkit/googleapilibraries.html). > > There currently aren't any plans to provide GData bindings in the GALGWT > project, but as you may know, the project is open source and we would > welcome any contributions if you were planning on creating bindings for the > GData JS library. > > > 2. In the scenario where you have an existing JS library that you want > > to make use of in GWT, what's the best, thinnest, way to to create a > > Java wrapper to the JS library? For example, we could create a Java > > class per JS class. The Java class could keep a reference to the > > native JSObject, and define the same properties and methods that the > > JS class provides but which delegate to the JS implementation via > > JSNI. The problem with this is that after compiling to JS, we end up > > with a JS wrapper around a JS object. Is there a better implementation > > approach that will avoid this? > > I think the easiest way to wrap the objects in the GData JS library is to > not actually wrap them, but overlay them with JavaScript Overlay Types (link > below). This is the technique that is used for the existing Google APIs that > have bindings in the GALGWT project and would be the easiest and best way to > provide support for GData bindings as well. The greatest thing about the > overlay technique is that there is zero overhead to pay for overlaying the > JS object. The one-to-one nature of the binding also makes it somewhat > intuitive for developers to follow documentation on the proper API as they > use it in their GWT project through GALGWT, so there's yet another win by > choosing the overlay strategy. > > JavaScript Overlay > Types:http://code.google.com/webtoolkit/doc/1.6/DevGuideCodingBasics.html#D... > > Hope that helps, > -Sumit Chandel > > > > - 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 -~--~~~~--~~--~--~---
Wrapping Around GData JS API With GWT
I have two related questions. 1. I couldn't find a GData Library for GWT, did i miss it (i already checked with the GData group)? I know GData has the Java API, but that (probably) won't compile to JavaScript. However, GData also has a JS API (the JS docs are here http://code.google.com/apis/gdata/jsdoc/1.8/index.html), so at a minimum we could wrap the JS API in a very thin GWT library - i'm wondering if this already exists or if it's planned as an addition to the list of GWT Google API Libraries (http://code.google.com/ webtoolkit/googleapilibraries.html). 2. In the scenario where you have an existing JS library that you want to make use of in GWT, what's the best, thinnest, way to to create a Java wrapper to the JS library? For example, we could create a Java class per JS class. The Java class could keep a reference to the native JSObject, and define the same properties and methods that the JS class provides but which delegate to the JS implementation via JSNI. The problem with this is that after compiling to JS, we end up with a JS wrapper around a JS object. Is there a better implementation approach that will avoid this? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
