-
31 Jan 2013 2:52 PM #11
Hi Colin, absolutely understand what you say and agree that is not a GXT issue. For the moment, just lets keep the thread open as we both agree that is an interesting idea and having GXT extensions in Chrome can be really great (https://chrome.google.com/webstore/category/extensions). As commented I just started with extensions so I do not have enough knowledge to solve the issue yet. But I will update the thread when I learn more or maybe somebody else. For the moment, just wanted to understand what other people was doing on this and if there was a solution already known by the community.
Thanks :-)
(PS: I did not use the zip file. Instead, I deployed a new GWT with Eclipse and it creates the demo project itself)
-
31 Jan 2013 3:46 PM #12
I was referring to the zip file in your blog post.
-
31 Jan 2013 4:23 PM #13
Hi Colin, yes I know, but I am not the owner of the blog. :-)
http://hello-its-crazy.blogspot.com/...using-gwt.html
I tried what he proposes in the post with the demo application created by the GWT Eclipse plugin and, for me, worked perfectly... except for connecting to server side. I did not need to use the code that he provides. However, the comments below signed by Adolfo in this post are mine. I asked him the same questions but he did not try connecting to server side either.....
-
31 Jan 2013 5:24 PM #14
By the way, responding to a previous question:
If it is a S.O.P. issue, no amount of client code will fix it. Maybe the manifest can be made to instruct the app to ignore such security features, but I doubt it
Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, but they're limited by the same origin policy. Extensions aren't so limited. An extension can talk to remote servers outside of its origin, as long as it first requests cross-origin permissions.
http://developer.chrome.com/extensions/xhr.html
So it looks a matter of finding the right set of permissions in the manifest.json.
-
31 Jan 2013 7:24 PM #15
Despite I do not think is of much help because I am afraid this is not an immediate task, I am attaching here the demo project that the Eclipse plugin creates in my Eclipse, as is.
Version: Helios Release
Build id: 20100617-1415
GWT: 2.0.4
App Engine: 1.3.7
I say that is not an immediate task because I suspect that we are dealing with bugs in Chromium (?). I have removed the jars in lib folder because the file size.
-
8 May 2013 10:56 PM #16
Adding some info. It is possible to run Ext JS apps as Chrome extension. Eval restriction has been relaxed (I think). See message 69.
I tried and it works.
https://code.google.com/p/chromium/i...tail?id=107538
-
14 May 2013 2:38 PM #17
Just a note from my point of view on the SOP issue. It is possible to override the RPC Remote Service servlet on the server side and then replace the code that points creates the path to the RPC policy path, thus giving you the ability to run RPC with out an SOP hangup. (This could create other vulnerabilities that I'm not aware of). Although while it is possible to do, the challenge is versioning, b/c both server and client have to be compiled at the same time or there likely going to be a serialization problem. In other words, as long as the client and server side version match exactly, then RPC can be used if the servlet to remote service is overridden. If you want to know more ping me and I can find the code I used. I'd recommend using rest or a json system with CORs enabled b/c its easier to deal with, although I have to admit its nice to use RPC, I haven't done it with a Chrome plugin yet.

Brandon
http://docs.sencha.com/gxt-guides/3/
-
14 May 2013 2:53 PM #18
Hi Brandon, I see the troubles. The good news is that I am being able to work right by using Ext JS to create Chrome Extensions with REST and JSON so I took this one as the way to go forward.
Dealing into the SOP issue and rebuilding the link looks really a pain to me, I agree with you. =:-)
Thanks,
Adolfo
-
14 May 2013 2:56 PM #19
Good to hear. Good job.



Reply With Quote