Opgenorth.NET

Update November 20th:  Well, a quick search of StackOverflow.com, and it turns out that I’m not exactly alone in this matter.  According to this post (and Grant in the comments of this post), in versions of IE < 8, one must use the click event, and not the change event.

I ran into an interesting issue today.  I don’t really know the answer, but I figured I would blog about it so that I don’t completely forget it.  While I highly doubt the two readers of my blog (my brother and sister) have any idea of what I’m talking about, I’m sure that eventually somebody (smart) will stumble upon this via Google.  What will happen in that case is anybodies guess, but I digress…

I had some JavaScript (note that I’m using jQuery too):

   1:  $(document).ready(function() {

   2:      $('#myCheckbox').change(myCallBackFunction);

   3:  }

   4:  

   5:  function myCallBackFunction() {

   6:     // unwrap protein strings and cure cancer in parallel on a single core system

   7:  }

For the sake of completeness, here is a sample HTML snippet to go with the above jQuery:

<input id="myCheckBox" type="checkbox"  >

Now, in FireFox 3, when you clicked on the checkbox, myCallBackFunction gets executed (as I would expect).  However, in IE7, that doesn’t seem to happen.  This has me stumped.

Now, at work, I asked “Who is an expert in Javascript and jQuery?”.  Crickets chirped.  Dead silence.  A tumbleweed rolls on by.

I then asked “Who wants to make Tom look stupid?” – everybody jumps at the opportunity.  Go figure.  Anyway, back to our exciting tale.  To get around this, I couldn’t rely on the collective brainpower of myself and my co-workers to figure out what the problem is.  Instead, we deduced that it is better to go around the problem and try something different.  I had  to use the click event like so:

$('#myCheckbox').click(myCallBackFunction);

This works in both IE7 and FireFox 3 – not sure why.

Based on my past experiences with things, I’m sure it’s something I’m doing (or not doing).  Going over my past experience, I’m sure it won’t be me who figures out what I’m doing wrong.

Lately I’ve found myself doing a lot more web application development in Javascript.  Typically, I always seem to fall back on plain old Notepad++ or Visual Studio.  As a developer, the user experience in either is, IMHO, somewhat lacking. 

However, for the past week, I’ve been using RubyMine.  RubyMine is a Ruby on Railes IDE from Jetbrains, but it seems to work rather well for editing Javascript and HTML files.  Plus, as an added bonus, it automatically comes with built in support for jQuery.

Curious about RubyMine?  Why not come to the Edmonton Code Camp on November 29th, 2008 and see it in action during my presentation on jQuery?  Or better yet, download your own copy and check it out.

<rant>
Now this may strike the one or two readers of blog as odd (assuming they haven’t fallen asleep or navigated away by now) – a lot of what I do is ASP.NET Development (WebForms and ASP.NET MVC), so shouldn’t I have been doing a lot of JavaScript up to now?

Well, if you allow me to digress a bit, my answer to that is “No”.  I’ve said it before, and I’ll say it again that, as a web developer relying very heavily on WebForms in the past, nothing has done more to emasculate my Javascript skills than Microsoft’s ASP.NET WebForms.  ASP.NET Webforms, with it’s emphasis on making development as VB6-like as possible, seems to encourage you do try and do everything server-side.  I know that I’ve sat in on at least one presentation by Microsoft employees who have spoken disparagingly of Javascript.  This is just plain wrong, IMHO.  Ask me why in person, if you’d like to hear the full rant.

Note:  This is my opinion.  Lots of people are happy with Webforms, and if you are, good for you.  I’m not.  Direct all comments and opinions on my viewpoint to /dev/null. 
</rant>

Well, I don’t know why it’s taken me so long to get to get around to this: but I must say that there are now a couple of "must haves" in my web developer’s tool box.  One of them is jQuery, and now the other is QUnit.

Chad Myers has a good, quick, post introducing QUnit, I’d strongly suggest checking it out if you do web development (which, IMHO, implies some use of JavaScript, right?).  Chad’s post covers the basics pretty good, and I think I would just be duplicating/plagiarizing Chad’s work if I were to blog the hour or two I spent getting to know QUnit here.

It is nice to see that JavaScript is slowly being recognized as first class citizen of the web programming world, and is gradually having it’s good name cleared of certain falsehoods.  It’s been my belief and observation for a while now that ASP.NET has done a pretty good job of stunting and retarding the adoption/use of JavaScript amongst .NET developers, at least in the Edmonton region.  Good to see that this attitude is starting to change.

As far as web developer’s go, I’ll freely admit that my Javascript is not one of my strong points.  I don’t have a real good reason for this, it’s just that over the past few years I haven’t had much call/need to polish and hone my Javascript skills.  Recently I discovered jQuery, and I must say that I wish I had know about this library earlier.  The more I use jQuery, the more I like it.  The simple things are simple, and the hard things are possible.  Take calling a simple webservice when the user clicks a button on a form.

Client side, the user would click on a button in their browser, in order to "check out" or "check in" – pretty simple stuff.  Click a button, update a record in the database.  I wanted this done via AJAX, as the page itself is pretty heavy with data, and I didn’t want to go through the whole page lifecycle.  I spent some time Googling how to do this on the web, but I didn’t find anything that seemed to be suitable for something as simple as this.

So, enough boring stuff, on with the issue.  In my current application the ASP.NET web service that the client should call looks something like:

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[ScriptService]

public class CampaignProductCheckoutService : WebService, ICampaignProductCheckoutService

{

  [WebMethod]

  public void CheckIn(int campaignProductId, int loginId)

  {

    // Do something...

  }


  [WebMethod]

  public void CheckOut(int campaignProductId, int loginId)

  {

    // Do something...

  }

}

Pretty simple webservice, nothing fancy.  Here is the corresponding Javascript on the browser:

$.ajax({

  type: "POST",

  url: "CampaignProductCheckoutService.asmx/CheckOut",

  data: "campaignProductId=3&loginId=4",

  beforeSend: function(xhr) {

    xhr.setRequestHeader("Content-Length", "campaignProductId=3&loginId=4".length);

    $("#progressBarContainer").show();

  },

  dataType: "xml",

  complete: function (xhr, msg) {

    $("#progressBarContainer").hide();

    if (xhr.status == 200) {

      alert("Happy Times!");

    }

    else {

      alert("Wailing and gnashing of teeth!");

    }

  }

});

This looks busy, but in reality, it isn’t. Now, for a detailed explanation of what is going on here, I’d suggest reading the book jQuery in Action.  It is a most helpful book for learning jQuery.

Anyway, here is a quick rundown of what is going on:  the $.ajax is a jQuery method that will perform the AJAX call, using the parameters that we provide it.  jQuery will perform an HTTP post to web service specified in url.  As part of the POST request, you can see that we’re passing in the parameters for the webservice call.  So far, pretty straightforward.

The next line, beforeSend, is a javascript method that jQuery will call before it does the POST.  In this case, we make sure that the request header has the length of the data being sent, and we show a progress bar to the user.  The funny syntax you see there is how we select the DIV element holding our animated gif and display it to the user.

Your standard ASP.NET web service will return XML to the client, and we inform jQuery of that with the dataType parameter.

By default, jQuery will perform the AJAX call asynchronously, so in the final line we provide another Javascript callback.  jQuery will call this function once the request is finished.  In this case, we hide the DIV element holding the progress bar, and we check the XMLHttpRequest object that is returned from jQuery. If the status is 200, then all okay and we display a happy message.  Otherwise we assume the request failed, and display a sad message to the user.

There you have it, a quick and dirty explanation of using jQuery to call an ASP.NET Web Service.

One thing I noticed since I started doing ASP.NET programming back in 2002: I started using Javascript a lot less, and my copy of JavaScript: The Definitive Guide sits on the shelf gathering dust.  I’ve noticed a lot of developers I’ve worked with are the same way. In fact, I’d say that most of the ASP.NET programmers I’ve worked with these days really don’t know much about Javascript.

I don’t blame Javascript itself for this – I blame ASP.NET. Developers just get used to dropping the server side controls on their WebForms, and then doing everything server side. I’ve also worked at clients which had a "no client-side javascript" rule. All of this combines to cause our (my) Javascript skills to atrophy and wither. Kind of shame, really. (note: to a degree, I think the same can be said about CSS).

Now, I think that when MS-MVC is released, this will change. As places being to use MVC more, I can see Javascript becoming more important in my day to day work – perhaps even to the point of becoming a first-class language again.
Javascript didn’t rape my dog – that’s because ASP.NET has pummelled my Javascript skills into a coma. But, I suspect that in the near future, a healthy dose of MS-MVC will revive my Javascript. I’d better start thinking about how to protect my dog.