However, for the past week, I’ve been using RubyMine.  RubyMine is a Ruby on Rails 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. 

Of course, this rant doesn’t apply if you’re using ASP.NET MVC or MonoRail.
</rant>

Updated August 10, 2010 : A bit of time has passed since I first wrote this post, figured an update couldn’t hurt

These days I seem to use a combination of Notepad++ and Firebug.  Firebug truly rocks.  It would be really nice if it worked for Internet Explorer, but it’s probably more realistic to hope for universal peace or an end to world hunger.  I’m told IE9 is supposed to have some good stuff for JavaScript development, but I somehow doubt that will help me out when I have to debug IE7/IE8 issues.

I’ve had some people in the past suggest Visual Studio 2008 whenever I do an informal poll.  Personally, I’ve found the JavaScript editing experience in VS2008 to be lacklustre at best. 

When WebStorm was in beta, I tried that combined with Firebug.  I rather liked it for my JavaScript editing needs. 

If you have any favourite tools (or IDE’s) to help with your JavaScript/jQuery development, I sure would like to hear about it.

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.

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.

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.

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.