Sometimes you do something for so long that you just assume everyone else is doing it, and then one day you find out that may not be the case. Recently I had this experience related to building applications that are “configurable by default”.
For at least the last 5 years, all the web mapping apps we’ve built set themselves up based on configuration information. That is to say, we don’t have hard coded layers / mapservice references in the application code – all that is passed into the app.
I think we really started using this pattern when the first ArcGIS Viewer for Flex came out. It standardized this model, albeit with Xml files. Since then both we’ve migrated both the Flex viewer and our own javascript bootstrap code to read json based configuration.
In cases of statically served apps (.html pages) this is simply written into the page. In apps that are hosted in larger server side frameworks (ASP.NET MVC) during initialization, the javascript or flex code makes a call back to a json api, which returns the configuration based on the credentials of the user. Still other times we inject the json into the page, again creating the configuration based on the user credentials.
An Example…
The exact format of the configuration data changes from project to project. For example, the “Compare” viewer that’s part of the Esri Change Matters Landsat viewer application has a pretty complex configuration because it is defines base maps, multi-temporal Image Services, including defining raster functions, and corresponding legend chips, as well as additional configuration parameters for the mobile versions.
This screen cap shows the “legend” that is setup for each of the 6 Image Services so that users know what these false color images mean. You can view a “pretty” version of the json in this jsfiddle, or view source on the Compare Viewer and see it in-lined into the page.
Configuration: Not Just for Maps!
Once you start working and thinking this way, the pattern starts to seep deeper and deeper into the code. The Colorado DOT Highway Data Explorer that I talked about at JS.GEO (video here) in January 2013 makes heavy use of this same technique. The configuration on this app includes all manner of things, down to hashes for setting up table columns.
But It’s Harder…
Of course it is! Anything worth doing tends to be difficult, but in this case it’s only marginally more complex. And any extra effort pays off when the you are asked to “just add this one more layer”, or “can we switch layer x and y”. The more we rely on configuration, the more the core code is reusable between applications. Using json for this is great because it’s so easy to adapt as you develop the code – need something else passed it? No problem – just edit the hash!
For those wondering, when we need to lock things down, but still keep things simple, we usually just put this information into json files in a secured folder, and then have the app look at the user’s roles, and then stream down the correct config file.
Have fun configuring your apps!