Jay Kimble

[Welcome to my multi-part tutorial on. I know I did an introduction earlier in the month, but before we dig in deep into this I thought it would be good to get a few questions out of the way.]

Why is this (Client-side Scripting) all that important to me?
You may be thinking "Hey Jay, my company bought Telerik/Component Arts/Component One/{fill in some other ASP.NET tools suite} and it seems to do everything I need and more. I can see some places where a little client-side code is helpful, but it’s not that important, is it?"

Well, I’m definitely not one to criticize the third party tools vendors, but their tools are just that tools. If your site grows large enough you will run into a place where you need to tweak their tools, and my experience is that all the ones I’ve mentioned have really nice client-side APIs that underlie their server-side components. Stuff that will really let you push the envelope of their tools. But, you probably already know that. The hard part is for all the great things these tools can do, sometimes you need something else (usually a little more light weight). In order to do this you need a background in client-side technologies so that you are able to assess your solutions. 

For instance, in my day job I created an MS Ajax behavior that takes a regular HTML table and adds a selection behavior. We did this to replace the big name grid we are using because, while this grid does amazing things, it also comes with a price of a heavy footprint and a larger than desired viewstate (we’re trying to slim our pages for performance sake). I also have created 2 additional behaviors: one injects client-side paging to a regular HTML table, and the other provides sorting functionality via the column header row. All of these behaviors inherit from a common class that wraps the table. My lightweight behaviors are simple components that can handle up to about 1000 rows which make them really useful for smaller sets of data. I tried them on as many as 5000 rows which gave OK but sluggish performance, and with 10,000 rows was simply unusable (I was using all three components, so it might be possible to use say just the paging and get decent performance).

It comes in handy to be able to build these types of lightweight components (which incidentally only took me about 40 hours to build all 3 which included server-side extenders).

Our first term: Client-side (or Ajax) Behavior
Since I have thrown the term "behavior" out a couple of times, let’s go ahead and define what it is exactly. In the realm of MS Ajax (and other frameworks), a client-side behavior is a client-side component/class that injects functionality into an HTML element. In MS Ajax, it is a separate component that is associated with an HTML element. When activated, it usually sets up UI events (onclick, onfocus, etc.) to intercept some UI interaction and apply new interactions. It can also inject additional css classes/styles or html elements on the page to apply a particular look (which is what the Ajax Control Toolbox’s Drop Shadow and the Rounded Corners behaviors do). It all depends on what the component needs to do. If you have played with any MS Ajax toolbox on the server side, you have probably throw Ajax Extender controls on a form; extenders are a server-side wrapper for the client behaviors. I hope that’s clear. If not fire off some comments to me at the bottom of this post and I’ll try to better explain in the comments (and will update this accordingly).

One of my goals for this blog series is to take you from knowing a little bit about client-scripting (and maybe nothing) to being able to build your own behaviors and extenders.

JavaScript is like a foreign language to me... Why couldn’t this be easier?
This may shock you, but I struggle with it too -- and I’m a(n admittedly) self-proclaimed guru with it. Two weeks ago (I was off last week) I wrote a very simple JavaScript component/class and I forgot something. I set up a timer event and it wasn’t making the call correctly into my class. Eventually I realized that what was happening was that I was calling a method within my JavaScript class and the instance of that class was being lost. I needed to use the MS Ajax "Function.createDelegate" function to get a wrapper function that wouldn’t lose the instance of my class. This is a total pain in the you-know-where. I actually told my boss that this is the exact reason I use Script# since it takes care of this stuff for me.

What the Heck is Script#?
Script# is a life saver! It is the invention of Nikhil Kothari (MS Ajax Architect and SilverLight2 Architect, and he is one of my heroes... I hope I get to meet him at Mix09). What it does is let you write C# code in Visual Studio against a framework (either Nikhil’s or MS Ajax... there are also jQuery extensions and a few others for it as well). This framework has a set of CoreLib replacements (System, etc.) that consist of set of .NET dlls and a set of JS client libraries. When you compile this code, you get a DLL which can be used in other Script# projects (yes, there are VS templates for creating a new Script# project), and  a set of JS files (debug and shrunk runtime versions). Script# makes it easy to create multiple inherited classes (an object tree if you will) as well as it handles things like passing functions around.

So that means I don’t have to know anything about JS right? Cool!
Hang on there! You will need to know a little bit about this stuff as it will help you read the code generated by JS. You can always patch bugs with Script#, but testing will (at this time) always exist in the JS side (in a browser), so you need to know enough to get around the source code that gets generated. The line numbers will always point to a line in the generated JavaScript (for instance), so your going to need to be able to read the JavaScript file and determine where the problems exist (you can still fix the code in your C# code, and can write debug messages that show up in the JavaScript console (or in VS if you are debugging the script running in IE).

So next up will be a column on JS OOP Basics.