RSS--> JSON--> On-Demand Script Tags and ASP.NET [AJAJ]

"You can observe a lot just by watching." --Yogi Berra, Berra's Law

I've been experimentng with some server side code that I already had, namely, a method that will get any RSS Url and turn it into a DataTable.

What I've done with that is to add the ability to convert that DataTable into a JSON data object, wrapped in a callback. With that done, it is a relatively simple matter to create a javascript source file that will "inject" not only the call to the aspx page that serves as the dynamic javascript "src" generator, but also the the UI for the DOM to display the results, and the callback method itself. It really doesn't take a lot of code to do this; in fact I used Jason Diamond's Manager class from the Anthem.Net framework to generate the JSON from the datatable more or less "out of the box".

The neat thing about this sort of approach is that there are now so many services and sites that return content and news via RSS that it's becoming almost ubiquitous. Even if they don't return RSS, you can still use Libraries like HtmlAgilityPack to parse out what you want and still put it in the format of a DataSet or DataTable. The end goal might be to create a library that is capable of retrieving or even web scraping most any kind of content whether RSS or not, and massaging it into a consistent "Delivery Vehicle" that always behaves the same.

The Hypocricy of Web Standards

Let's look at the hypocricy of so -called "Web Standards" for a moment. We are gonna tighten up security on the XMLHTTP object in modern browsers to prevent it from requesting content from any domain other than the one that the page has been requested from, yet we freely allow a Javascript <Script> element to access content from anywhere! Does that make sense? Sure it does, in a strange way: If you were consistent, and did the same thing with script tags, Google, Yahoo and every other contextual advertising service would go APESHIT! So, go figure.

Developers all over, in virtually every discipline from ASP.NET to PHP to Ruby, are using "AJAJ" - Asynchronous Javascript and JSON. Probably it should be referred to as ODJAJ - On - demand Javascript and JSON. But then, we have enough acronyms already, wouldn't you say?

This is an experiment to play with the concept. You can enter any search text in the "SEARCH" textbox below, and either TAB out or click outside the textbox and you should get your search results. This will work in most browsers, including IE 6 and 7 and Firefox.

In modern browsers, XMLHttpRequest is constrained by what is called "Same Origin Policy". This allows the interface to only connect with the server that delivered the base page, and the rule deals with some common, long-standing security flaws in web architecture. If this policy were not in place, then the user could be harmed by XSS (cross site scripting) attacks.

The Same Origin Policy frustrates these attacks, but it also frustrates a larger class of legitimate uses - developers like you and me wanting to provide quality, performant "Web 2.0" - like applications. It should be possible for a script in a page to access data from other servers without compromising the security of the user or his organization. In particular, it should be the USER who gets to make this choice as an informed choice, NOT for it to be made in a sledgehammer fashion for him by the browser instead!

Surprisingly, the Same Origin Policy does not apply to scripts and that is why so many developers have begun to dynamically generate <script> tags to connect to any server. The server sends back a script which delivers some data. Unfortunately, this script runs with the same authority as a script from the originating page, allowing the script to steal cookies or directly access the originating server, or do virtually any of the things that the flawed "Same Origin Policy" attempts to thwart. This is unsafe.

Douglas Crockford, the originator of the JSON data format, proposes a standardized approach to solve this problem here. I like Crockford's approach, although I do not believe it will ever be implemented.


What you see below this textarea is completely the result of this single script tag:
<script src="http://www.eggheadcafe.com/articles/seachRelated/searchTitle.js"></script>




The point of all this is that by using JSON, combined with the option of an on-demand-script tag (e.g., adding a script tag and its dynamic src property to the DOM programmatically) we get around the lousy cross-domain security restrictions of the XMLHTTP object in modern browsers. When the script tag is added to the DOM, the script is automatically executed in the client browser. You are welcome to stick the above script tag into a page of your own and experiment.

For those who are still "JSON-Challenged", JSON is built on two structures:

A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.
These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangable with programming languages also be based on these structures.

In JSON, they take on these forms:

An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma).
An array is an ordered collection of values. An array begins with [ (left bracket) and ends with ] (right bracket). Values are separated by , (comma).
A value can be a string in double quotes, or a number, or true or false or null, or an object or an array. These structures can be nested.
A string is a collection of zero or more Unicode characters, wrapped in double quotes, using backslash escapes. A character is represented as a single character string.

Except for a few encoding details, the above entirely describes the notation. Unfortunately, people are already referring to JSON as a "language"; (including Crockford himself, on his site). It is not. JSON is a javascript - parseable data format for encoding objects. A programming language consists of the grammar used to construct a computer program; you cannot create a program with JSON, you can only describe objects that can be interpreted by Javascript, which is a programming language.

Please understand that I sometimes use my UnBlog as a sandbox for my experiments. I got one comment on the last post complaining about this that and the other thing; it had nothing at all to do with the subject of my post. If it doesn't render correctly in "FireFart" or whatever browser you are using besides "Internet Exploder", try to get over it, OK?

I'll have more soon, including some nice ASP.NET generic source code for a sample "Serving" page, an HTML form that will convert your script creation into all the "document.writeln" statements to create your script src file including any DOM elements you want and a Javascript callback method, and simple instructions on how you can "roll your own". Probably, I'll post this as an article on eggheadcafe.com and when I do, I'll update this post with the link.

NOTE TO BLOG SPAMMERS

You people don't get it, do you? I don't know why you would bother going through all the CAPTCHA stuff to post your "Mortgage Rates Online" crap. It only takes me a second to delete them. Get a life, Scum!