Julio, you can try using JSONP, if your external CGI page is capable of returning valid JSON data. If it's not your case, the only possible way is to write server-side code at your backend, and serve data from your own host
On Dec 8, 3:22 pm, julio <[email protected]> wrote: > Hi Thomas thanks for your reply. > > > The "xs" linker only allows you to load the GWT app (*.nocache.js et > > al.) from a different origin than the "HTML host page". This is > > because the default linker ("std", or IFrameLinker) uses an iframe to > > load the *.cache.html and then hits the SOP when trying to communicate > > with the host page. The "xs" linker does not use an iframe but instead > > load *.cache.js files directly in the host page. > > Ok so it's not my case. > > > > Have you any idea? > > > There's no way a browser can contact a "remote public CGI (not under > > [your] control)" if that one doesn't explicitly allows it (using > > CORS), and were it the case then it would only work for those browsers > > that support CORS (recent versions of Firefox, Chrome, Safari and > > Opera; IE8 supports it but with a specific API that GWT doesn't use). > > if I paste and copy the remote cgi's url in the browser bar the data > get displayed on it (Firefox 3.5.12, IE6 and Chrome 8). > In this case something is still possible? > > Thanks, > Julio -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
