I'm having a similar problem. Also I am running this from my local file system [ATTACH=CONFIG]15793[/ATTACH]
Please use a local web server. It's not realistic to run web apps from your local file system. There are plenty of free options and most OSes come with a web server built-in.
Seems that you may have a "Access-Control-Allow-Origin" issue for your local html file. You can try to publish the html to the web server and access it using
I'm having a similar problem. Also I am running this from my local file system [ATTACH=CONFIG]15793[/ATTACH]
Please use a local web server. It's not realistic to run web apps from your local file system. There are plenty of free options and most OSes come with a web server built-in.
Hey derek, I know this was a change that had to be made, but up till 2.8 everything ran fine as a local file. It was MUCH more convenient. This seems like a major step backwards.
Please use a local web server. It's not realistic to run web apps from your local file system. There are plenty of free options and most OSes come with a web server built-in.
Hi Derek,
Thanks for the clarification. However, I agree with Jeff that this represents a new hurdle for developers (especially those just starting out with the JS API).
While it's not realistic to run web apps from a local file system, it IS common to fire up a quick sample to check how one specific thing works, which is surely the point of the samples? This is how we test out new functionality before compiling it into a robust web app for deployment (not just in the ArcGIS Server JS API but in other web mapping APIs, or indeed other JavaScript/HTML libraries).
I haven't looked into v3.0 yet so I don't fully understand the change, and why it was necessary. As a developer, all I can see is that the copy/paste/test approach used to work, and now doesn't. Perhaps there could be a blog post/tutorial explaining the changes, and giving some simple instructions for the new requirements of a web server - this could be linked on each sample page.
Thanks for the clarification. However, I agree with Jeff that this represents a new hurdle for developers (especially those just starting out with the JS API).
While it's not realistic to run web apps from a local file system, it IS common to fire up a quick sample to check how one specific thing works, which is surely the point of the samples? This is how we test out new functionality before compiling it into a robust web app for deployment (not just in the ArcGIS Server JS API but in other web mapping APIs, or indeed other JavaScript/HTML libraries).
I haven't looked into v3.0 yet so I don't fully understand the change, and why it was necessary. As a developer, all I can see is that the copy/paste/test approach used to work, and now doesn't. Perhaps there could be a blog post/tutorial explaining the changes, and giving some simple instructions for the new requirements of a web server - this could be linked on each sample page.
Cheers, Steve
Spot on; everything addressed here is a valid concern and well said.
I believe the reason for this a Dojo 1.7 issue and not an ESRI API issue. If run locally, Dojo will try to load the files locally, which is why you get these errors. Let's look at the dojo/text tool. It will load a file as plain text to use in your application, mostly used for templating. This a XHR request, which cannot be done locally and will only work in a server environment.
It can be a little annoying if you are not used to keeping a server up locally.
It's a simple, one-click install of apache/mysql/tomcat and more. You can just use it to run apache which will work for running the samples. There's even a version to run it off a usb drive. I've been using it for quite a while at work so I don't need to work off a test server.
