Jeff and .NET

The .NET musings of Jeff Putz



My Sites


January 2008 - Posts

Gotchas and learnings from refactoring to use ASP.NET AJAX

I promise that one of these days soon I'm going to talk a little about where POP Forums v8 is headed, and what you'll be able to do with it. I don't imagine there's a huge demand for the app, but regardless, it will be available.

In any case, I spent some time the last few evenings refactoring most of the Javascript stuff in the app. Some of it is bona fide AJAX, but other pieces are just using the framework to make Javascript seem more object-oriented and reusable. Along the way, I've learned some things that hopefully will at least make their way into search results so others don't have to endure similar pain.

Delegates are your weird friends

Describing delegates in C# is hard enough sometimes. In Javascript it's even more weird. There are several areas where you absolutely need to know how they're used. One of the more useful things already in Javascript is the setInterval method, which allows you to fire off some event at a regular interval. It takes the method you want to fire and the interval in milliseconds in which you want to fire it as parameters. With straight blocks of script, functions and such, it's easy enough to just pass in the method name. When used inside of a method in a prototype, it has to be wrapped in the Function.createDelegate() function provided by the framework. Take this class, for example...

PopForums.UI.ExpandContract = function(boxID, selectorText) {
    this._boxID = boxID;
    this._selectorText = selectorText;
    this._inertiabase = 5;
    this._interval = 10;
    this._inertiabaseoriginal = this._inertiabase;
    this._slideinterval = 0;
    this._newHeight = 0;
    this._box = $get(boxID);

PopForums.UI.ExpandContract.prototype = {
    executeExpandContract : function() {
        this._targetHeight = this._getHeight().replace("px", "");
        if ( == "none" || == "") {
            // expand
            this._slideinterval = setInterval(Function.createDelegate(this, this.expand), this._interval);
        else {
            // shrink
            this._newHeight = this._targetHeight;
            this._slideinterval = setInterval(Function.createDelegate(this, this.shrink), this._interval);
    shrink : function() {
        if (this._newHeight > 1) {
            this._newHeight = this._newHeight - this._inertiabase;
            this._inertiabase += 1;
   = (this._newHeight > 1) ? this._newHeight + "px" : "1px";
        else {
   = "none";
    expand : function() {...

This class opens and closes a div in the nifty decelerating fashion we see on various sites. The kicker here is that the functions in the class that do the work on interval must be referenced using the Function.createDelegate() method or they won't work. The reason? Something known as closure, which is frankly too computer sciency for most people to be bothered with.

The same is true of using the callbacks for async calls using Sys.Net.WebRequest from within a class. For example, consider this block in a function defined in a Javascript prototype:

            var request = new Sys.Net.WebRequest();
            request.add_completed(Function.createDelegate(this, this.populateResponse));

PopulateResponse is another function defined in the prototype, and again, you need to wrap it in Function.createDelegate(). The long and short of this is that it exercises closure so that the function referenced in the delegate has context within the instance of the class you've created. If you read that Wikipedia link, you can see why closures make sense when dealing with asynchronous calls.

Serialization and you

Few things are as uninteresting as serialization, but when it isn't done efficiently, you get giant blocks of data being transported back and forth over the wire, slowing down your app. XML is sweet, but it can be a little on the heavy side for a lot of AJAX work. Fortunately, JSON is already Javascript, and it's a little less verbose than XML. By marking a WebService derived class with the ScriptService attribute, you're well on your way to JSON goodness coming down the pipe. When the WebService is referenced via the ScriptManager, it's as easy as calling the service by full name (because a proxy will be established by the ScriptManager), and then using the properties of the returned result object, to a degree, as if it were the same kind of container object on the server.

The stuff that's a little harder to get into

There is a lot of power I've yet to tap, not the least of which is more use of callbacks and delegates to orchestrate stuff happening between objects on the page. Granted, you need to have something in mind to start using these pieces (I do), but there's a lot of potential there to make everything easier to read and maintain.

Then there's the bit about Intellisense and script debugging in Visual Studio 2008. Frankly, the Intellisense is not all it's cracked up to be, and I find the scope of what VS "knows" about to be limited. I don't blame the IDE as much as I blame the fact that you can pretty much do whatever the hell you want in Javascript, whenever you want. The debugging is kind of a pain to, because for it to attach to the right processes, you have to run the app, which I rarely do because that's still a slow process. It's also not that useful when you're working on a page that's the product of URL mapping or some custom handler, or there's a query string on the page. I still find myself spending more time in Firebug, but maybe that's just because I don't use VS right.

Overall, I can't even tell you how excited I am to continue working with the AJAX framework. The more you use it, the more you see its potential. Much of it can't be realized by using the sparse and poor documentation online though. A good book really helps (like ASP.NET AJAX In Action, even though it does not cover WebMethods called within pages).


You know you've been neglecting a coding project when...

...You realize that it has an SMTP client class that you wrote to be more flexible than the System.Web.Mail classes that wrapped CDONTS back in the day before .NET 2.0, and it's still there. Ouch. 

On science, religion and actually shipping code

Frans had a really good post about some things he has observed in the "" world. Honestly, with all of the blog posts I see on this "movement" lately, you'd think there was a cure for cancer just around the corner. As if it's that important.

I think the single most critical thing mentioned in Frans' post is this:

"...The consequence is that the result of working on that idea has its root in the tool, technique or pattern, not in fundamental research in computer science. This result causes other ideas, which causes other results etc. etc.

Is this bad? I don't know, but if these two worlds drift apart, and the more I think about it, the more this is going on already, the consequences could be severe: the world in which research is taking place isn't feeding the world which applies techniques/tools/patterns with fundamentals, that world of techniques/tools/patterns is feeding themselves with 'fundamentals', which is actually cyclic reasoning: the fundamentals aren't fundamentals, they were the results of applying fundamentals, which doesn't make them fundamental per se."

Asking if this matters is in fact the one of the most "right" questions I've seen on the topic of computer science and the ensuing religions that crop up around it. A lot of people spend a lot of time thinking about computer sciencey stuff, and that's fine. There is a place for these kinds of discussions for sure, though what Frans describes is obviously not the science he thinks should be discussed.

So that said, what are you left with? To me, it's just noise. I suspect that I'm not alone.

I've enjoyed mentoring other programming types, writing my book and seeing myself get better at what I do every day. I think it's important to crave professional development. But here's the thing, I'd be willing to bet that at least half of the people who do what I do have absolutely zero formal computer science training. Lots of English degrees where I work. If we're being completely honest, I don't think very many of us even care about computer science, beyond learning things we find useful. Our biggest concern is shipping product.

There is a place for academic pursuits of computer science. But as much as I believe everyone should know what the factory pattern is, I can't imagine people spending a lot of time thinking about this stuff. We're headed in the direction that CPU design has gone. A few extra smart people design processors now, and the rest of us drop them in a socket. Programming techniques are important to know up to a certain level for most of us. It's helpful for me to know some performance considerations, for example, but I could care less how the compiler works.

There are a lot of different levels to this, certainly. It sounds though that what's happening in the community that Frans writes about, people are participating at a level they're not qualified to participate in. Honestly, that's not a slam on anyone, it's just a reality. But given my previous posts about developer snobbery, the "I'm an MVP" posts and other marks of entitlement or self-appointed praise, I think the amount of useful knowledge that comes out of these discussions is low for the majority of the world.

I'm not suggesting they shouldn't take place in public, I just feel somewhat, I dunno, disappointed that so much energy is spent on science project discussions. 

Valve and Half-Life 2, plus Steam, three years later

It's strange how some posts on this blog get comments even to this day, one of them being a post about how Valve's Steam was a pile of crap that seemed to drag down Half-Life. I remember even later that year, my former wife has many complaints about it.

Well, problem solved. I got the Orange Box for the Xbox 360, and I'm enjoying Half-Life 2, three years after my first try, and at a much higher resolution than I could have back then. I guess good things do come to those who wait.

But I still maintain my point from back then. Why is it that everyone who writes something for Windows insists that it always be running? 

Scoble screwed up, and won't man up about it

Robert Scoble annoys me. I used to enjoy reading his blog, but it has gone to a point where he really thinks he has all the answers and is the smartest blogger on the Net, masked thinly by the occasional self-deprecating comment or whatever.

But now he got booted off of Facebook because he was using an automated script to take all of the contact information from his 5,000 friends and dump it into Plaxo. Are you seeing the irony here? This is the same guy who called out Zuckerberg at Facebook for screwing with people's privacy and not owning up to it. Are you kidding me?

Here's the big news flash, Scoble... I added you as a friend to see what you were up to, not so you could suck out even my name and e-mail and put it in some other system. Why do you think I'd be OK with that?

Facebook should drop you out on your ass. You screwed up. Now admit it, the way you expect everyone else to when they screw up. 

Why open source won't cure cancer

This essay by Jaron Lanier is one of the smartest things I've read about the open source "movement" and its influence on software design:

Twenty-five years later, that concern seems to have been justified. Open wisdom-of-crowds software movements have become influential, but they haven’t promoted the kind of radical creativity I love most in computer science. If anything, they’ve been hindrances. Some of the youngest, brightest minds have been trapped in a 1970s intellectual framework because they are hypnotized into accepting old software designs as if they were facts of nature. Linux is a superbly polished copy of an antique, shinier than the original, perhaps, but still defined by it.

Before you write me that angry e-mail, please know I’m not anti–open source. I frequently argue for it in various specific projects. But a politically correct dogma holds that open source is automatically the best path to creativity and innovation, and that claim is not borne out by the facts.

Well said. Really when you cut through all of the warm fuzzies and get down to what happens in practice, there's an argument to be made. I too agree that there is a time and place, but it won't cure cancer.

More Posts