Persisting Model State with JSON

I’m departing from my normal show a lot of code methods here, to talk about an idea.

ASP.NET MVC denegrates ASP.NET Web Form’s old state-maintenance construct called Viewstate.  Without Viewstate, many developers are wondering how — more aptly where — to preserve the state of a web-application.  Here I will be explaining my favored answer — serializing your model to JSON — and showing why.

SOME HISTORY

In ASP.NET Web Forms, page state was stored within a highly compressed, encrypted hidden form field.  This allowed .NET web developers to persist the state of the GUI controls with little-to-no effort.  Unfortunately, AJAX came along.  AJAX developers found ASP.NET Web Forms didn’t play nicely at all; and that since Viewstate was encoded, AJAX developers couldn’t easily work-around ASP.NET Web Forms limitations.

ASP.NET MVC

The Model-View-Controller architectural pattern could easily be called the state/GUI/event-handler pattern.  Personally, I feel that most ASP.NET MVC examples nail showing off the Controller, and by proxy do a pretty alright job showing off the View.  But simple examples often have simple domain logic, and hence the Model and state-maintenance has been largely ignored.  This is important to note, because HTTP is a stateless protocol, yet the MVC pattern was designed for persistantly stated desktop applications.

“The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).” – Steve Burbeck, from the paper first describing MVC

STATE MAINTANENCE IN MVC

Given the statesless nature of HTTP, most ASP.NET MVC examples imply that the Model is little more than a “page model” with some supporting domain logic.  For the Model to act across multiple pages, we must persist that model between page requests… and we have options… databases, mutiple hidden form fields, sessions, cookies, etc..

The common denominator is that each page request must somehow reconnect to its Model.  In many cases, the Model — or at least the current pertinant chunk of the Model — is small enough to reasonably be persisted with each page, much as Viewstate was.   The huge advantage to custom Model persistance  comes in saving the Model to a hidden-form-field in the form of Javascript Object Notation, or JSON.  Using JSON means that not only will the Model be persisted, it will also be available for AJAX developers to update without full-page-postback.

ISN’T PUTTING THE MODEL IN THE VIEW BAD?

Considering the alternatives, no.  Sure, persisting the Model to a database would have some security benefits — at the expense of connection overhead.  Sessions or cookies work as well — with their own known limitations.  You could also — God forbid — break your model into little bits and persist each one as necessary.   Let me say this is the WORST possible thing you could do, because it requires the View to know the entire Model to do its job.  The code to serialize to JSON is the same for any object you throw at it, and changes to the Model won’t have to be duplicated in each View.

CONCLUSION

Of course, there are limitations to persisting your Model via JSON.  HTTP Get/Post have character limitations you must consider.  You will want to validate your model on each page post.  Overall, however, the benefit to AJAX developers outweighs the security awareness necessary to implement this state-management architecture, and prevents your ASP.MVC architectures from falling into the rut of “page-state”.

AGS SOE’s without the SOAP

Vish recently wrote about calling AGS SOEs via SOAP instead of DCOM.  He doesn’t mention that AGS doesn’t make you use SOAP, nor XML for that matter. This low-tech JSON-RPC invoker shows the proof-of-concept:

public string HandleStringRequest(string Capabilities, string request){
  MethodCall mc = JavaScriptConvert.DeserializeObject<MethodCall>(request);
  object result = this.GetType().GetMethod(mc.name).Invoke(this, mc.parameters);
  return JavaScriptConvert.SerializeObject(result);
}

public string test(string str1, string str2){
  return str1 + str2;
} 

class MethodCall{
  public string name;
  public object[] parameters;
}

 Here’s an action shot…

ASP.NET MVC + Ext + WCF

Dave Bouwman wrote up a nice post about using MVC with AJAX.  Dave’s example, however, requires manual serialization / deserialization.  Fortunately, Omar Al Zabir wrote a filter that leverages WCF’s DataContractJsonSerializer to accomplish just this. 

I’ll spare the code duplication, but here’s how to call it from Ext:

 Ext.Ajax.request({
    url: ‘/myUrl.mvc/testDTO’,
    headers: { ‘Content-Type’: ‘application/json’ },
    success: mySuccessFunction,
    failure: myFailureFunction,
    jsonData: myJavascriptObject
});

Json rtrees

I’m having fun posting this from my iPhone, in NYC. Nate Irwin and I are working on implementing r-tree spatial indexing in Javascript.

Some quick testing proved that building an index clientside was too slow, so we’re building the r-tree serverside and serializing to Json.

On a 6500 feature dataset we’re getting .01s (FF) to .03s (IE) search times — fast enough for on-mouse-move GUI response.

The only caveat is that JSON nodes consisting of integer IDs and double-precision bounding-boxes run ~85 bytes per feature. Above 2500 features you must consider wire-size. Including attribute data would quickly bring this over the top.

However, optimizing the leaf node structure for point data and g-zipping the r-trees should run <3 bytes per feature — making clientside indexing of 100,000+ features within reason.

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.