-
14 Feb 2013 5:36 AM #1
Answered: Specify URL for services?
Answered: Specify URL for services?
Hi,
We have an ExtJS application with java serverside controllers for getting data.
Right now, when I build the app, and tries to run it, I get a few error messages in the chrome inspector (remote debuggin):
XMLHttpRequest cannot load ionp:///services/locales/no_NB?_dc=1...mit=25&start=0. Origin ionp:// is not allowed by Access-Control-Allow-Origin.
XMLHttpRequest cannot load ionp:///services/user/loggedin?_dc=1360848310135. Origin ionp:// is not allowed by Access-Control-Allow-Origin.
Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101
Is there anywhere to specify URL's to use when calling java controllers etc? Or is functionality like this not supported yet? Guess it should be possible to build the java classes into this app also or something.
This is the contents of my .json file:
Code:{ "applicationName": "Projectname", "applicationIconPaths": ["HelloWorld.ico", "HelloWorld.icns"], "versionString": "1.0", "outputPath": "build/packager", "webAppPath": "build/projectname/production/", "settings": { "mainWindow": { "autoShow": true }, "allowCrossSite": true, "remoteDebuggingPort": 9100, "security": { "allowFileSystemAccess": true } } }
-
Best Answer Posted by jarrednicholls
"allowCrossSite" belongs under the "security" config object. Try moving that there and repackage your application. Let me know if this helps! Thanks.
-
14 Feb 2013 5:42 AM #2
Were you using json store/proxy? If this is the case, you might probably want to google for jsonp store/proxy. If you are using java at the backend, this filter might be useful to you, as you don't need to modify the logic in the backend. If you are using other backend than java, this might be a reference to implement another filter, too.
Code:public class JSONPRequestFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest = (HttpServletRequest) request; if (isJSONPRequest(httpRequest)) { ServletOutputStream out = response.getOutputStream(); out.println(getCallbackParameter(httpRequest) + "("); chain.doFilter(request, response); out.println(");"); response.setContentType("text/javascript"); } else { chain.doFilter(request, response); } } private String getCallbackParameter(HttpServletRequest httpRequest) { return httpRequest.getParameter("callback"); } private boolean isJSONPRequest(HttpServletRequest httpRequest) { String callbackMethod = getCallbackParameter(httpRequest); return (callbackMethod != null && callbackMethod.length() > 0); } }
-
14 Feb 2013 6:02 AM #3
Aha, so I need to change all my json proxies on the client side to jsonp proxies? and then it might work? Doh :P Just giving this a try though, but it seems like a cool idea.
-
14 Feb 2013 6:07 AM #4
Yes, I believe you have to do change to all client stores/proxies from json to jsonp. But this should not be very painful.
-
14 Feb 2013 11:43 AM #5Sencha - Desktop Packager Dev Team
- Join Date
- Mar 2007
- Location
- Baltimore, MD.
- Posts
- 1,745
- Vote Rating
- 5
- Answers
- 20
"allowCrossSite" belongs under the "security" config object. Try moving that there and repackage your application. Let me know if this helps! Thanks.
-
15 Feb 2013 5:00 AM #6
Ok, I got it working with adding allowCrossSite under security, and making some changes to the URL we use when calling.
But I have a couple of questions..
History is removed (why not just hidden??), so if you have based your application on history navigation (which everyone should), it becomes useless when packaging application. (Can't navigate at all)
Cookie is removed. Why not just keep this in some way in the packaged app? Seems strange to deactivate it.
All in all, I thought the meaning of this was just to create a "shell", and hiding browser specific things from the view of the users. If not, we will have to implement 2 versions of the application as it is now.
Frank
-
15 Feb 2013 7:46 AM #7Sencha - Desktop Packager Dev Team
- Join Date
- Mar 2007
- Location
- Baltimore, MD.
- Posts
- 1,745
- Vote Rating
- 5
- Answers
- 20
We have cookie support coming in our next release. History persistence is a good feature request, thank you. There are plenty of use cases for using window.history back()/forward()/go(), agreed. Our focus out of the gate was supporting single-paged applications e.g. Sencha Architect which do not navigate or operate using history management, but instead use menu items and desktop-y UI. We'll put history management on the list.
This is meant to be a shell, but with obvious host integration enhancements. A good portion of the browser feature-set is integrated custom from the bottom-up, not from the top-down. E.g. for cookie support, we have to build that support in, hook up a cookie jar, persist the cookies to the right location that segregates your application's cookies from other SDP applications' cookies, etc. We will have to similarly hook up and enable history. It's not as simple as just removing the browser chrome. Don't hesitate to point these omissions out, we want to make sure your use cases are addressed, particularly if your code runs in a standards compliant browser. Thanks!
-
18 Feb 2013 2:33 PM #8
Hi,
I just read the interesting post about changing all store proxies to jsonp, but how do I change the "base url" of the jsonp proxy dynamically? Let's say I have an ExtJS application with several stores to be available externally (i.e. given in a REST based service with a different URL per installation), how to pass the application the URL of the REST service when starting the app?
-
18 Feb 2013 11:49 PM #9
Hi,
In our project we have overridden Ext.data.Connection, and the "setupURL" method. So I just hardcoded the URL there. I'm sure it's possible to read that from some kind of config file or something also if you need to change it based on where you are.
Frank
Thank you for reporting this bug. We will make it our priority to review this report.


Reply With Quote
