I have an interest into going into detail over the serialization framework provided by ASP.NET AJAX. The reason - ultimately - is that I would like to start explaining how the Animation framework works in ASP.NET AJAX. However, as with any sort of understanding, there are earlier pieces that must be grasped first before you can truly understand the later pieces: the "crawl before you walk" problem. So, let's start off with the basics and, over the next couple days, we'll move our way through the serialization framework and into the Animation framework of ASP.NET AJAX. Doing so, you'll be able to really start cooking with some fascinating animations in your browser-side programming. My goal, also, is to aid you in understanding how it all works under the hood (as usual).

So, let's explore JSON.

JSON - the JavaScript Object Notation - is a "stringified" version of an object; or an object represented as human-readable text. It is valuable because the web, primarily, doesn't do well with raw, binary data....as you know, the data must be encoded so that it can be properly transmitted via the web medium (learn more). However, it is more space-savvy then various alternatives (such as XML), thereby making it more appealing to transmit large, detailed blocks of data (such as objects).

The basic idea behind JSON is that when you need to transmit some object over the web boundary, you serialize it in the JSON wire-format, make the transmission, and then deserialize it on the receiving end into the original object. The result is a clean hand-off of the object from one universe to another across the finicky web. The actual data format isn't important; though if you are interested Wikipedia has a nice overview of it here. But, suffice it to say that in JSON, you're taking some opaque object and representing it as a block of ASCII-based text.  

Why is it important?

In ASP.NET AJAX, especially, JSON is VERY important. Why? Because ASP.NET AJAX is striving, very hard, to be as strongly-typed as it can at all times for objects written in ECMA script. Objects are flittering and flying about all over the ASP.NET AJAX world and, therefore, a consistent wire-format for transmitting and working with those objects is necessary. As we will see when we start encountering the Animation framework of ASP.NET AJAX, serialization via JSON is used extensively in converting the animation XML into maleable, server-side objects that we may program against; likewise, those same objects on the server can be serialized into meaningful JavaScript objects for the client-side framework. All of this is done using JSON formatting in ASP.NET AJAX.

How does it work?

I mentioned earlier that the formatting rules of JSON isn't important - and for us, as ASP.NET AJAX programmers - it isn't. The reason is due to the fact that we rarely ever need to hand-tweak anything because formatters for JSON exist and are quite mature already, on both the client AND the server-sides. However, there is a powerful framework at work here that deserves a bit of understanding, regardless of the actual formatting rules.

At the core, the most important element required for JSON serialization within the browser itself is the eval() method. The eval() method takes a block of data, which can be either script or JSON data, and evaluates it. The "evaluation" process will do something to the text; if it's script, then it will execute it, otherwise it will go through and parse out the JSON data and return a deseralized object back to the script. There are security implications involved in this sort of process, and so you should be very cautious to leverage eval() on your own. Instead, you should use Sys.Serialization.JavaScriptSerializer as an ASP.NET AJAX developer. This type exposes two, obvious methods: serialize() and deserialize(). Under the hood, this JavaScriptSerializer object leverages eval(), but more cautiously.

So, JSON works by leveraging API frameworks that convert the formatted data to objects and back again for us.

Conclusion

In the next part of this topic I'll go over the actual process of taking objects represented in XML and creating ECMA script from them (and back again); a process that is used extensively in the Animation framework of ASP.NET AJAX to work with the animation objects declaratively.

Lately I've started becoming more and more interested in the business side of social networking - its effects on business, marketing and the like; it's really quite a fascinating social phenomenon.  I think I’ve always had an interest in a number of things in my life – obviously software development (the under-the-hood, nuts and bolts, creative pursuit of developing a solution to a problem) has always been a major interest, but so has business.  Due to the fact that the world is starting to catch up to the fact that computers are “cool” and, therefore, my investment in them has become more marketable and social, my interest in business has grown even further; now to the point where I think I might start blogging on not only topics related to .NET development, but also the business applications of that development in many areas.  

Personally I think the next big “wave” in the world of business is going to be in how it leverages the new social medium to reach, interact with, and learn from customers (current or potential). I think, in many ways, this has already started – companies like Microsoft, Sun and even McDonalds are using RSS in some form or another to reach out to their customers (their communities). It’s all just very fascinating and I think that if we – as developers – can keep our eye on this new and interesting market, we might be able to all profit from it highly. Remember that we have a power that those who pay us do not; if we watch over their shoulders and keep our focus one step ahead, we can be the ones cutting the paychecks.  

          Anyway – if I write enough on this topic I might create a separate blog dedicated to just that so that the focus here doesn’t drift too much. I guarantee I have plenty to write out in the future in .NET development, but I also promise there’s going to be a lot more on the practical applications of that development.

I'm going to be on a cruise in the Mediterranean next week - so I won't be posting :P I'll try to take some nice pictures and show them here when I get back.

Have a great week everyone.

Please Note: You must enable Script Debugging in Internet Explorer in order to follow what you are about to see here. Please do this!

Also.....Beta-1 warning here - things will change.

I find it very interesting to watch how our development environments have changed over the past few years; I remember a long, long time ago writing an entry about doing debugging of javascript in Visual Studio 2003. In any case, I really think I would like to walk everyone here through doing this in the new Visual Studio 9.

One of the coolest parts of Visual Studio 9 is the intellisense feature that you get with JavaScript. Therefore, let's do some intellisense and script debugging of ASP.NET AJAX client code through the new Visual Studio 9. To start, I create a new web solution in VS 9 and add a reference to System.Web.Extensions (for ASP.NET AJAX). I then want to add my ScriptManager control to the page, followed by a HTML button that I will execute some custom ASP.NET AJAX client script on a HTML textbox. The end result looks like this:

Next, I hook up an event handler in JavaScript with the button by double clicking it and getting presented with a method body:





In the spirit of ASP.NET AJAX being "asynchronous" I will then code into it a WebRequest class that will make an asynchronous call to any URL that is placed within the textbox. As you can see below, I have full intellisense making the use of the Sys.Net.WebRequest class a breeze:



I will then complete my use of the WebRequest class. I run into a bug, however - some null reference exception in my nicely formatted, intellisensified code. The code looks alright from the outside, it looks like this:




...but yet in the browser I get an error whenever I try to click the button, regardless of what I have in the textbox. So, let's set a debug break point on the text I'm about to pass into the set_url method and see what happens:




It says requestURI is null. So, I must have screwed up somewhere in my code?!? So, I look back on my code and realize I'm using the 'nodeValue' property instead of the 'value' property. A quick change of the code and I now get the following:




Slick, huh? Oh, and please note that even though I'm using "cnn.com" here, you won't be able to unless you are actually hosted on cnn.com. To prevent malicious scripting, you can only cause an asynchronous request to your own domain through ASP.NET AJAX.

I'm placing this here as a note to read this again someday (and hopefully to have others read it). What a great article - http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/.

Very brief overview:

1. Reduce the time and number of round trips to the database by returning multiple resultsets.
2. Learn to optimize the paging feature of ASP.NET's GridView control.
3. Leveraging connection pooling (http://www.ondotnet.com/pub/a/dotnet/2004/02/09/connpool.html).
4. Understand and use the ASP.NET caching API (http://aspnet.4guysfromrolla.com/articles/022802-1.aspx).
5. Think about caching data frequently used during the lifetime of a single request.
6. Background processing. Here I'm dissapointed he didn't mention asynchronous pages in ASP.NET - but I know what he's getting at (http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/).
7. Page-level output caching (http://aspnet.4guysfromrolla.com/articles/022802-1.aspx).
8. Run IIS 6.0 (7.0?). He really likes (and so do I) the concept of kernel-mode page output caching.
9. Use GZIP compression. Duh (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/25d2170b-09c0-45fd-8da4-898cf9a7d568.mspx?mfr=true).
10. ViewState optimizations. Honestly - in my tasks, I turn off ViewState as much as possible.

OPC - the Open Packaging Conventions - is a recently approved standard for packaging data into a single, compact file. Many people, myself included, have had to create file structures in the past to maintain data in a single file; this creates a packaging standard for creating file structures in a discoverable fashion.

The coolest part about the whole thing is there is an API surrounding it in the .NET framework 3.0 - that is enough of a reason, alone, to be curious about it. It leverages ZIP as the compression format, uses a relational hierarchy for the contained parts and, like I said earlier, supports the concept of discoverability.

Check out this MSDN entry for more if you're curious about what this might provide for you: http://msdn.microsoft.com/msdnmag/issues/07/08/OPC/default.aspx.

MSDN Notes: Implementing the CLR Asynchronous Programming Model (Jeffrey Richter)

Source: http://msdn.microsoft.com/msdnmag/issues/07/03/ConcurrentAffairs/

1.       Introduction

a.       For applications that require interaction with IO, the answer is often to write into the solution more threads – this still incurs an overhead, however, in terms of the operating system resources needed to spawn and manage threads.

b.      The better solution, according to this article, is to use the CLR’s Asynchronous Programming Model (APM) in lieu of the a more heavily threaded application.

c.       There are four main reasons, according to this article, why you would write a class that implements the APM.

                                                               i.      You’re building a class that directly interacts with hardware,

                                                             ii.      You might be building an abstraction layer atop a class or code base that already talks to hardware,

                                                            iii.      You may have long-running methods in your class,

                                                           iv.      You might be wrapping non-asynchronous Win32 functions.

2.       The heart of the APM: IAsyncResult

a.       Any class implementing APM has a Begin/End method (ex: BeginRead/EndRead) pair of methods. The Begin version must create and return an Iasyncresult object that is the center of APM model.

                                                               i.      The object can be queried for the status of the asynchronous operation and is used to determine the result when the operation is completed.

b.      IAsyncResult has a property – a wait handle – that is actually ineffecient to use and so ought to be avoided if at all possible (many asynchronous operations will have a callback anyway, signalling the end to the operation).

 

 

 

I'm not sure if this has been done before, but it might prove to be another way cross-site scripting is dangerous.

Right now I'm trying to create a global index of all corporate blogs on my new site www.blogsbycompany.com. I'm waaay off the target now, but it's a pet project I'm playing with at the moment (don't bother going to it - yet). Regardless, I'm seeing that people put HTML into their RSS feeds; I'm noticing it all over the place (and it does make sense). My site aggregates company blogs (I have about 8 thousand blogs right now - but, I'm not advertising the site because it's way off of where I want it), but I'm noticing that sometimes I get encoded JavaScript in my blog descriptions (I'm making sure that people are properly encoding the script or else I encode it for them before displaying it in the results page on my search site).

What this tells me is that if someone out there is poorly doing a web bot or a RSS aggregator site, they could potentially open their viewers up to someone running script in the browser or on the cilent through RSS feeds. Most people simply expect the RSS content to be nicely formatted, but if they foolishly try to decode script, they could really cause some damage to their readers.