While at Where 2.0, Chris Spagnuolo and I recorded a podcast with the Very Spatial crew.

In this podcast we talk (at a high-level) about internals of the Global Avian Influenza mapping application we built for the Wildlife Conservation Society, and some of the complexities and how we overcame them (think 1-M-M-M database relationships, with complex query criteria and 300ms response times).

For those that know us, you won't be suprised that we also talked about Agile - how it fits in with the Where 2.0 crowd, and how we work Agile into our contracting. All -in - all, a fun experience.

The podcast went live today. Thanks Jesse & Sue!

While I've messed with the Dojo Toolkit enough to get the interface elements up and running, I've been delegating a lot of the more detailed "wiring" work to Mike- "soon to be blogging"-Juniper, while I worked on the back end web services and database tiers. When I did wire things up, I tended to use the Microsoft Ajax Client-side Library.

Mike is out at Microsoft TechEd this week, so for my current project, I've got no one to lean on, so I'm digging deeper into the Dojo Framework.

For those not in the ArcGIS Server beta program, it's worth noting that the Javascript API that will be shipping with 9.3 is based on Dojo.

Here are a list of resources that I've been using:

SitePen Dojo Quick Start Guide 

Pretty quick read, but covers the main ideas so well that it has apparently replaced the old "Quick Start" guide that was on DojoToolkit.org

Book of Dojo @ DojoToolkit.org

This is a one-stop shop for what's in Dojo. Quality varies between the sections, but overall, a good starting point for what's in there. Covers Dojo, Dijit and DojoX.

Dojo Feature Explorer @DojoCampus.org

This is another good place to see what the controls can do, and you can see the code as well. Again not 100% complete, but covers much of Dojo, Dijit and DojoX.

Articles @ DojoCampus.org

Be sure to check out the articles on the site. They are pretty focused, but well written.

Have some other great Dojo Framework resources? Drop them in the comments!

Recently I needed to parse a complex query string from a Url, and configure a map based on those settings. This parsing occurs in the server side Page_Load event, and the general process of parsing the Querystring NameValueCollection is straight forward.

The complex part comes from the fact that my application is heavily Ajax based - other than the initial markup, everything else is fetched from the server via HTTP GET's to ASP.NET JSON web services. Still sounds good. But - here's the trick. The query string is passed to the page, not the web service. I guess I could have tried to write all the parsing in javascript and handled it on the client side but there are some pretty complex options that involve database lookups, and I like me some MBUnit Row Tests, so server side was a better option.

Just use Session State...

The first though is - ok - I'll parse the query string, and stuff the resultant "map settings" object into session, and have the client fetch that from the web service. Nice, but no cigar, since the web service can not access the HttpContext that the page is running in. So much for simple solutions.

ASP.NET Page Methods To the Rescue (or not!)

Next contender was ASP.NET "page methods" (aka web methods). These are static methods They should work, as they can access the HttpContext of the page. After parsing and stuffing the "map settings" into the session state, the client side code could call back to the "Page Method", which would grab the map settings from the session and send back to the client. Sweet. After some head scratching and reviewing of sample code that does this, and a bunch of Googling, I found that Page Methods do not work on User Controls (ascx). Since I was creating a module for use in DotNetNuke, there was no way around using a user control. Time to get ugly...

Serialize to Json and Cram into the Page...

Yep - the old inject-it-as-it-renders trick. Ugly, but it works. So, in page load, I parse query string, create and populate the map settings class and then use the System.Web.Script.Serialization.JavascriptSerializer  to convert my object to JSON. Some people have reported issues with this serializer, but it's been working smoothly for us so far. If you have problems, you can roll your own or use an open source option like JRock or JSON.Net. From there, I just emit it into the page as part of a script block:

As alluded to the in the comments, I ran into all kinds of trouble with dates. Read the referenced forum article for the "why" behind the string replacement bit.

Then in the client side Page_Load (I'm using the MSAjax stuff, so we get a Page_Load that automatically linked into the client page lifecycle), we use the client side deserializer to convert our JSON string back into a handy dandy javascript object.

//Deserialize back into an object
mapSettings = Sys.Serialization.JavaScriptSerializer.deserialize(mapSettingsJson);

From here we just proceed with the rest of the page startup, and we get the correct map.

Note for .NET 3.5:

If you have .NET 3.5 installed, then JavaScriptSerializer is marked as deprecated, and suggests you use the DataContractJsonSerializer. And if you are using Complex types (like I am) you will need to add the [DataContract] and [DataMember] attributes to the classes being serialized. I tried both ways and for me they both worked.

Yesterday I focused on the REST, and Javascript API's, and today's task is to get the skinny on the re-vamped .NET ADF.

In talking to some folks, apparently the .NET ADF includes a Javascript API based on the Microsoft Ajax client library. In contrast to the relatively simple Dojo based API, apparently this one has more depth, and with that (one would assume) comes more fine grained capabilities. So, we'll see what some pointed questions can drag out.

At a high level, I think that the .NET ADF may have a tough sell moving forward. The REST stuff is clean and elegant. It may be that on paper it can't do as much, but I believe that there are creative solutions that can step around any limitations. Secondly, everyone I've talked to who has used the 9.2 .NET ADF, well, I'll be charitable and say they are "luke warm" on it. The difficulties they faced in getting good performance, and implementing seemingly simple functionality is what will drive them to try the REST API before the .NET ADF. And if the licensing story for the .NET ADF remains the same, and the REST API is gratis, well, money talks.

I hope that the 9.3 ADF does more than support the ASP.NET Ajax "extender" model (this is how the Ajax Control Toolkit works). From my work with the toolkit (which has been restricted to the ModalPopupExtender and the ListSearchExtender), it's a nice model if you really want to keep your fingers out of the client side code. The difficulty is that since the extenders are setup as part of the page lifecycle, they seem to need everything they interact with to be "runat=server". For reasons I'll skip right now, this is not always easily done. Since all this behavior is implemented in the client, theoretically you can wire up events and use the client side code however you like, but in the Control Toolkit, this is not exactly documented (please send me details if you know otherwise!).

Getting back to the .NET ADF, I hope that the Javascript libraries are designed to be directly consumed and manipulated. Personally I like the Microsoft Ajax client library, and working with server side services is just a slick developer experience. So - I have high hopes.

The Javascript API is based on Dojo. ESRI has created some dijits for a map, and the basic pattern looks really similar to the Virtual Earth maps.

The Google Maps extended is just more javascript which extends the base GoogleMaps API to play nice with the ESRI services.

2D and 3D in Virtual Earth is also fully supported - again via javascript extensions.

Slightly different syntax across the APIs, but same basic patterns.

Embed maps and tasks into sites

Use ArcGIS Online or custom (ArcGIS Server) data sources.

Any supported projection. So you polar explorers are now in luck.

Javascript can be hosted by ESRI (like VE or Google Maps) and is in the Akami cloud (think fast, and globally cached - a nice touch).

Samples will be hosted in a live server. Much easier to dig into the samples because they are live. Can copy paste code into your html/aspx/??? file and start modifying. Very streamlined development cycle.

Examples working with a Dojox.grid (Nice because it takes a DIV as a target so the page layout is pretty smooth)

http://maps.esri.com/agsjs/surfaceprofile.html - surface profile demo

InfoWindow can contain whatever you want - i.e. another map

Symbology Model

Really nice demo of a symbol manager based on dojo controls. Incidentally it was running in FireFox on a Mac. Lots of options re: how client side features are displayed. Should be relatively easy to allow client symbolization. Again - looks very performant. They also have symbol sets. They will have a code-gen tool that will allow you to use this tool to setup your symbology, and then export the code to drop into your app. Also running in Safari. Only Solid_Fill supported in FireFox 2. All the saucy picture fills are supported in FireFox 3.

Again stressing the simple, but you'll need to have your CSS, HTML and Javascript chops in shape.

Virtual Earth Extender

Only Tiles - no dynamic layers, but all results can be sent back as VEShapes. Also an interative SDK. Looks just like the VE Interactive API. Javascript hosted by ESRI.

Google Maps Extender

Tiled layers or dynamic layers (via GGroundOverlay). The extender allows you to easily pump results back into GM. The Extender removes the need to convert between the native classes in the base API and the ESRI javascript API - i.e. you can pass a GM LatLongBound into a query. This should be a very smooth developer experience. 

Mapplets

Run within Google Map web site. Can be published to Google Maps. Pretty cool way to push stuff out.

Thoughts:

Again - this is really great stuff. Simple stuff is really easy, and I'm betting that the hard stuff is still difficult, but I'd wager it's miles better than the 9.2 ADF experience. We'll see what the 9.3 .NET ADF has in store at tomorrows session...

The information flow here is very important - design the application to show focused data in small chunks. This allows very small, fast transactions. That said, if you try to push tons of data into your browser, it will bog down.

Since the Javascript is hosted by ESRI, presumably anyone can just include it on a page. From there, you can consume the free ArcGIS Online services, and of course you can mash-in anything else you want. So it would see that there is a world of good free fun just waiting to be explored...

Based on the Super Tuesday sample site, we got a preview of what ESRI is planning in 9.3.

Map Widgit

Based on Dojox, ESRI has created some wijits (are they dijits if they are based on dojox?) of their own, which we can see in the dojo.require statements...

 dojo.require("esri.map");
 dojo.require("esri.tasks.query");

I'd assume there are more packages lurking around, but this is what I found in a quick look around.

I also noticed something interesting in the constructor for the map - usePlainJson - could this indicate that they have a compressed/encoded Json format? That would be really good, as you can get a lot of bloat when you start shipping around un-compressed JSON geometries. Google uses an encoding scheme, which John O'Brien has written up in an article, and implemented for Virtual Earth so that may also be in the mix.

You can see the javascript for these components here: (it's minified, so it's not exactly readable, but is publicly available) http://serverapi.arcgisonline.com/jsapi/arcgis/?v=1

Vectors in the Browser: Dojox.gfx

Dojox is the next generation of Dojo dijits which are pushing the edge of what's possible. The Dojox.gfx package provides an abstraction layer for dealing with vector geometries in the browser - it renders SVG or VML depending on the browser.

I'm glad that we chose to start working with Dojo, as it looks like it will come in handy really soon

In my opinion, the REST services and the Javascript API are "the" 9.3 features, and I'll be focusing most of my attention on this over the next few days.

I've been diggin in deep this week - at 4:30pm on Friday this was my desktop...

(click to view full res -500k)

I've got the ArcDeveloper REST project up, a testing site where I'm furiously mixing the Dojo Framework with MS Ajax, and a DotNetNuke module where I'm bringing it all together...

This is just the start, but I've got Virtual Earth in a Dojo Split Container, (there will be a Dojo Tree in the lovely light blue area) with a Dojo Toolbar (icons to be changed). Not shown but also working are some Dojo dialog forms. The orange blob is a feature brought into VE via the ArcDeveloper.net REST service. I still have to wire in some point clustering, and the tree view, but given it's been a productive week.