Recently, as I was slowly working my way through Rebecca Murphy's excellent js-assessment test suite, I ran into a problem that was quite vexing. I was creating a function that was to take an arbitrary number of arguments and combine them with an existing array. I thought that this would be as trivial as using the concat method on the existing array and passing in the arguments object. However, as you can see below, it didn't work.
JS Bin
For a while I thought that I must be using the concat method incorrectly. I tested it using the terminal again and again with no problems. Finally I recalled a recent issue from A Drip of JavaScript that talked about the arguments object. I remembered that Joshua said that the arguments object "isn't exactly an array, [but rather an] object that acts like an array." This means that you can's use it exactly like an array. An easy fix for the situation was to bind a call to the slice method on an empty array to the arguments object which converts it to a true array object like so:
JS Bin
Hopefully this will save you some time in the future and also convince you that you should really subscribe to A Drip of JavaScript. Each week there is a great article that is short enough that I can read it without feeling like I have to dedicate a bunch of time and yet in depth enough to give me some useful knowledge.
Tuesday, December 24, 2013
Tuesday, November 26, 2013
Using Base Maps with Non-standard Coordinate Systems in LeafletJS
Since LeafletJS seems to be what all of the cool kids are using these days and it shows no signs of slowing down, I thought that it would be fun to figure out how to use Leaflet to view AGRC's awesome base map services. This presented a unique challenge since they are not in a projection that is supported out-of-the-box by Leaflet (UTM Zone 12 NAD83). However, I found that it is possible with the help of a few additional JavaScript libraries. So, here's the solution:
ESRI-Leaflet & ArcGIS Basemaps
You'll notice that I've loaded these libraries in addition to the latest version of Leaflet:
The implementation was not that complex once I got all of the numbers right. First I create a new Proj4Leaflet coordinate reference system which I pass into the map constructor. Then I use the Esri-Leaflet Plugin to set up a new TiledMapLayer and add it to the map.
Now you can be one of the cool kids too!
ESRI-Leaflet & ArcGIS Basemaps
You'll notice that I've loaded these libraries in addition to the latest version of Leaflet:
The implementation was not that complex once I got all of the numbers right. First I create a new Proj4Leaflet coordinate reference system which I pass into the map constructor. Then I use the Esri-Leaflet Plugin to set up a new TiledMapLayer and add it to the map.
Now you can be one of the cool kids too!
Tuesday, October 15, 2013
Mac OSX + VMware Fusion + ESRI's ArcGIS Server
While there's endless arguments about whether Mac's or PC's are better for web development, there's not much argument that Mac OSX is the most popular platform for web development today. A few years ago I noticed this trend and decided to make the switch from Windows to Mac for my personal computer. For the most part I have not looked back. It was really nice to be able to follow along with tutorials online and use all of the great tools that are built for the Mac. However, this post is not about convincing you to make the switch; it's about how to use a Mac to develop ArcGIS Server JavaScript applications. It's about how to have your cake and eat it to.
When I finally asked to make the switch to a Mac at work I was faced with a problem. It was not a big deal to spin up a VM with windows server to host ArcGIS Server. However, I didn't want to develop from within my VM. I wanted to continue to use the great development environment that I had in OSX. I also didn't want to write apps that hit ArcGIS Server cross-domain. Hitting ArcGIS Server from localhost on my Mac like this was my goal:
After a few months of messing around, I finally came up with a stable solution that works well. I now do all of my testing and development in OSX and am still able to hit ArcGIS Server with relative urls (
The first goal was to be able to serve projects that are located within my OSX file system through IIS on my Windows Server 2008 virtual machine. This is accomplished by setting up a shared folder in VMware Fusion (Settings -> Sharing).
Then I set up a virtual directory in IIS that points to that shared folder.
I don't think that the host name matters as long as you have the correct mac (hardware ethernet) address from your VM.
This change gave my VM the permanent ip address of 192.168.247.100. Then by adding line 55 to
and voila!
I can now write and debug my apps on my Mac but have them served up through IIS on my windows VM.
When I finally asked to make the switch to a Mac at work I was faced with a problem. It was not a big deal to spin up a VM with windows server to host ArcGIS Server. However, I didn't want to develop from within my VM. I wanted to continue to use the great development environment that I had in OSX. I also didn't want to write apps that hit ArcGIS Server cross-domain. Hitting ArcGIS Server from localhost on my Mac like this was my goal:
/ArcGIS/rest/services...
) from within my apps. I accomplished this with a few tricks within the virtual machine software that I use, VMware Fusion.The first goal was to be able to serve projects that are located within my OSX file system through IIS on my Windows Server 2008 virtual machine. This is accomplished by setting up a shared folder in VMware Fusion (Settings -> Sharing).
Then I set up a virtual directory in IIS that points to that shared folder.
Make sure that you have the
\\vmware-host\
in your path. I had to hand type this in to get it to work. This enabled me to hit my web apps that were stored on my Mac from my Windows IIS. However, to hit my VM from my Mac, I still had to use it's ip address. This was a big pain because by default it is not static which meant I was always having to check my VM's ip address and I couldn't bookmark anything.
Finally, I came across an article showing how you can assign a static ip address to your guest and then forward localhost on your host to your guest. The first step is to assign a static ip address to your guest VM by appending
/Library/Preferences/VMware Fusion/vmnet8/dhcpd.conf
. You can read the article for the specifics of what to add. My addition looks like this:I don't think that the host name matters as long as you have the correct mac (hardware ethernet) address from your VM.
This change gave my VM the permanent ip address of 192.168.247.100. Then by adding line 55 to
/Library/Preferences/VMware Fusion/vmnet8/nat.conf
I was able to forward localhost
on my Mac to IIS on my VM...and voila!
I can now write and debug my apps on my Mac but have them served up through IIS on my windows VM.
Monday, September 9, 2013
The ESRI API for JavaScript/Dojo Build System Saga Continues...
That's right, my entire app JS is in this one file *including @ESRI modules* http://t.co/06S4KCtkuR cc @DavidSpriggs @derekswingleyThis is my third post on this topic. First, there was discard layers. Then AMD threw a curve ball. And now a little bird told me that, starting at version 3.4, there is a special build of ESRI's API for JavaScript that is straight up minified AMD modules with no layers files. I'm not sure why this hasn't been more publicized. It's just a little minification away from releasing their source coded. And, as I will outline below, it allows you to build an honest-to-goodness layer file without any of the superfluous code that past versions required. This means that you can build all of the JavaScript code for your application including Dojo, ESRI and your own modules into a single, minified file.
— Scott Davis (@ScottAGRC) May 21, 2013
To load the new AMD build of the ESRI API for JavaScript you just append "amd" onto the end of the url. For example, js.arcgis.com/3.6amd (3.5 requires something different because something is messed up with their build: http://js.arcgis.com/3.5amd/js/dojo/dojo/dojo.js). You should be able to just make this one change in your app and it should still work. You may need to explicitly require a few more ESRI modules now that you are not getting a bunch up front with their layer file. With this build you have to load each module individually. So it's going to slow down your load time significantly. It took our boilerplate from 128 requests to 337 requests to load the unbuilt, source version of the app. Needless to say that you should never use this url in production! In fact, I don't even use it during development because it takes so long to load.
The real usefulness in the new AMD build happens when you feed it through the Dojo Build System. The first step is to scrape it to your machine. In order to do this, I needed a list of all of the ESRI modules and other resources like images and .html files. I started with their argument aliases doc and then filled in the gaps by hand. It was easy to see what files I was missing since the build system returns errors for missing dependencies. After I had a good list of files, I used a bash script to pull the files down to my local machine. Here's the script:
The files cannot be fed directly into the build system as is. You'll notice that, in the script above, I had to fix some artifacts from their build (e.g.
define('dep1,dep2,dep3'.split(','))...
) as well as some paths to the dojo directories. After running this script you have the entire ESRI JavaScript API as separate modules that are ready for the build system. This is so ridiculously close to having the actual source code (just a bit of minification), I wonder if they are just going to release it in the future.After getting the ESRI modules onto your computer, it's just a matter of pointing to them in your build profile and you are good to go.
You can see the entire set up for this process in AGRC's JavaScript Project Boilerplate. Hopefully the next blog post is about how awesome it is that ESRI has finally released their source code. ;)
Monday, April 15, 2013
ESRI JSAPI 3.4 and the Dojo Build System
[Update: The Saga Continues]
In a previous post, I outlined how I use the Dojo Build System to optimize my web app code for production. Specifically I showed how I get around the problem of working with ESRI's ArcGIS API for JavaScript library which has already been run through the build system. However, with their recent upgrade to AMD-style module loading my handy trick of using:
So I headed over to #dojo to see if the experts had any ideas. Fortunately for me, brianarn was there and was aware of the problem. After some brain storming, we came up with the idea to use a custom loader plugin for loading ESRI modules. Since the build system doesn't try to flatten modules that are imported with nested requires, we hoped that importing them through the plugin would solve my problem. The plugin was a relatively simple implementation:
You can put this module within any package and use it like this:
Using the plugin to load ESRI module effectively prevents the build system from trying to include them in your layer files thus allowing the build script to complete successfully. Of course, none of this hacking would be needed if ESRI would just release their source code. :)
If you find a better way of getting around this problem or have any other suggestions please let me know in the comments section below.
In a previous post, I outlined how I use the Dojo Build System to optimize my web app code for production. Specifically I showed how I get around the problem of working with ESRI's ArcGIS API for JavaScript library which has already been run through the build system. However, with their recent upgrade to AMD-style module loading my handy trick of using:
dojo['require']('esri.map');
... to fool the build system into skipping 'esri...' modules imports didn't work anymore. I had no idea how to exclude modules when loading them like this:
define(['esri.map'], function (Map) { /* ... */ });
So I headed over to #dojo to see if the experts had any ideas. Fortunately for me, brianarn was there and was aware of the problem. After some brain storming, we came up with the idea to use a custom loader plugin for loading ESRI modules. Since the build system doesn't try to flatten modules that are imported with nested requires, we hoped that importing them through the plugin would solve my problem. The plugin was a relatively simple implementation:
You can put this module within any package and use it like this:
define(['app/EsriLoader!esri/map'], function(Map) { /* ... */ });
Using the plugin to load ESRI module effectively prevents the build system from trying to include them in your layer files thus allowing the build script to complete successfully. Of course, none of this hacking would be needed if ESRI would just release their source code. :)
If you find a better way of getting around this problem or have any other suggestions please let me know in the comments section below.
Subscribe to:
Posts (Atom)