Tiny Flex/AS3 XML Settings Loader

I have been writing a lot of Flex code recently.
Somehow, I’m most pleased with this *tiny* little class to load XML settings from the HTML container.

The joy here is that Flash/Flex can *only* load data asynchronously… this class allows settings to be pulled in sychronously, before anything else, and with very little effort.

package com.wordpress.mapwrecker
{
	import flash.utils.Proxy;
	import flash.utils.flash_proxy;
	import flash.external.ExternalInterface;

	dynamic public class Settings extends Proxy {
		private var data:XML;

		public function Settings() {
			//load settings from parent HTML document
			if(ExternalInterface.available)
			{
				 var getSettingsRequest:String = "function(){ return document.getElementById(\"settings\").innerHTML; }";
				 var response:String = ExternalInterface.call(getSettingsRequest);
				 data = XML(response);
			}
		}

		override flash_proxy function getProperty(name:*):* {
			return data.children().(localName().toUpperCase() == String(name).toUpperCase());
		}
	}

}

JSON vs. Flash for Distributed Mapping

A few years ago I wrote a “Flash connector” for the ArcIMS HTML Viewer.  This “connector” took advantage of Flash’s security sandbox model, which allows cross-domain data connections under special, protected circumstances.  The point was to allow ArcIMS to get around JavaScript’s “same-domain policy” limitation — to allow distributed web-map calls without a proxy. 

Really the point was to put an ArcIMS HTML viewer on my HTML-only web-resume host, but I digress.

 In the browser, ArcIMS’s JavaScript and Flash communicated via Flash’s “External Interface” methods.  ArcIMS could post ArcXML to and from other domains.  Flash’s security model requires a “crossdomain.xml” be published on the remote-domain.  Jan Bliki’s excellent Flash + ArcIMS work at the EEA offered both the ArcIMS backend and “crossdomain.xml” to test all of this against.

The whole point, again, was to get around JavaScript’s ”same-domain policy” limitation.  Fast forward to 2007 where JSON is commonplace.  One accepted JSON paradigm is On-Demand Javascript – a special case where JSON-encoded data may be accessed across domain boundaries.  Essentially, an HTML <script> tag may be dynamically generated in the DOM, thus loading the JSON data.  There is some debate whether this is a feature, or a bug. 

For a moment, I considered rewriting my “Flash connector” as a “JSON connector”.  However, the lack of domain restrictions on DOM-based JSON requests does not apply to XmlHttpRequest JSON requests.  This means that JSON data may only be loaded via an HTTP “GET”; you can “POST” information to remote domains.  Hence, Javascript still cannot POST data to remote domains.

Overall?  If you’re not interested in proxying, 2-3 year old Flash technology is still better than JavaScript.  Why?  The security model.  Microsoft has been hinting at giving Silverlight a permissive cross-domain policy.  I suggest they do so.

Let me know in the comments if there is any interest in me posting a “Flash-connector” walk-through.

Silverlight first impressions

Being a .NET GIS programmer, a former Flash developer, and an bit of a JavaScript hacker, I’m a natural to be interested in Silverlight.  I remember in 2003 when Microsoft first announced Sparkle (now Silverlight) in the frame of a Flash-killer.  In the mean-time, AJAX seems to have stolen the show.  Silverlight clearly represents a shot over Flash’s bow, but I have to wonder “how does Silverlight compete against AJAX?”

There is really little to say about rendering performance.  Early tests seem to show that WPF/e XAML rendering speed is comperable to Flash and DHTML.  Pretty good performance for a beta product.  Overall, WPF/e should work great for displaying small GIS vector feature datasets.  WPF/e is nicely integrated, and its straightforward how to programmatically create layout.

The part of Silverlight that interests me the most is its support for a subset of .NET.  Microsoft has a demo showing .NET for Silverlight running up to 1000x faster than Javascript, effectively 10-15x faster than Flash’s Actionscript.  Sweet.  In an odd coup, the DLR will allow you to write your Silverlight .NET code in Javascript, facilitating high-performance AJAX ports.  Beyond that, a quick look at the HTML bridge quickstarts shows that we need not rely on WPF/e XAML – Silverlight can bind to the HTML DOM quite handily.   Again, score for Silverlight. 

Here is where my opinion really starts to diverge.  I can’t find Silverlight’s supposed “serialization classes for handling data.” I haven’t seen them in the remoting quickstarts or a quick API examination.  Yes, there’s support for plain XML, REST, and SOAP… but I can’t find any automatic object/class-level serialization.  Until I see object serialization between ASP.NET and Silverlight, its not the JSON-killer I hoped for.

In fact, despite the high-technology, its hard to see what Microsoft has done here.  Certainly they’ve given their C# programmers a skyhook into browser-based development.  They’ve upped the computing-performance ante for browser capabilities.  That a pretty big deal.  However, Silverlight still comes off as direct competition against Flash, not a competitor to AJAX.  So why push out a zero-installation-base plugin when you own the browser marketshare?  Had IE7 matched Mozilla’s support for SVG/Canvas, E4X, and Javascript getters/setters — this would have given us 80% of the functionality of Silverlight’s limited APIs.  Perhaps because they’ve been planning this since 2003. 

 UPDATE:

As pointed out in the comments, Silverlight is based on AJAX in a very non-disruptive way.  The afforementioned support for SOAP is really support for ASP.NET AJAX JSON-enabled web services.  Beyond that, this is all documented exactly where I said it wasn’t … http://silverlight.net/QuickStarts/Remote/UsingJSON.aspx.  …And I wasn’t even trying to troll.

Overcoming Slow AJAX Form Serialization

Those of you familiar with Prototype know that Form.Serialize is one bad-ass capability.  The depressing part comes when you realize just how long serializing complex forms can take.

So how can you quickly serialize large forms for postback via AJAX?  Simple, you don’t.  Here’s how:

1) Post your entire page using a standard form submittal with an additional unique ID for the request.

2) Server-side, store the GET/POST data but don’t process it, return an HTTP 204 — “No Content”

3) Finally use AJAX to retrieve the GET/POST data … or retrieve the results from the form posting

Note that I haven’t actually tried this, but it strikes me as clean enough.  Sure its a nasty hack, but it beats serializing forms in JS, and if you wrapped it in a pretty OO JS class, people just might call you genius.