blog.dogma.co.uk

jQuery Ajax Dot Net 1.1.3 and Examples

2008-08-21T17:20:00.003+01:00

Version 1.1.3 contains a single bug fix in the parser. I have also uploaded two example Visual Studio projects, one for .NET 2.0 and one for .NET 3.5. The projects, in addition to the example calls, illustrate the plugins inability to send custom classes to the server. This is a feature I'm currently working on.

The example projects can be found here:

jQuery Ajax Dot Net 1.1.2

2008-08-12T21:33:00.004+01:00

A new version of the Ajax Dot Net jQuery plugin has been released. The release restructures the way the plugin parses server responses into a JavaScript object. The release is also split into packed and Intellisense versions.

Plugin Page

Google Maps JavaScript Intellisense

2008-08-06T20:58:00.006+01:00

I'm working on a project that uses Google Maps extensively. I've used GM for basic stuff in the past but that was pre API Loader and Visual Studio 2008. The API Loader is cool, I like namespaces it keeps everything neat, GMap2 looked too much like COM programming. google.maps.Map2 is something I can get into.

The namespaces got me thinking, someone must have found a way to get Intellisence for google.maps. The closest I could find was a blog post by Roger Chapman, his solution is pre loader and hand written, rather than the scripted solutions for jQuery (thanks to the way jQuery is documented). That said, I am extremely grateful for work that must have been time consuming and Roger is to be commended. Roger Chapman I salute you.

I have taken Roger's original file and namespace'd it. I've added a few lines to the top of the file which declares google.maps and the the API Loader functionality. Then, using Find & Replace, I switched all those ugly capital Gs and G_s for google.maps. I've also added one or two additional classes that weren't included in Roger's original file. I'll continue to add more as and when I need to. I'd certainly appreciate any additional classes that other people have added. The current version of the file is available to download here.

I believe Roger has since created a CodePlex project for his work. If there is any interest in me doing so, I'll contact Roger with a view to forking the project for the API Loader variation.

Square the Sum

2008-07-29T21:30:00.003+01:00

I'm teaching myself F#. It's the first time I've worked with a language of this type, it's also been a while since I spent anytime with algorithms. Maths was never really my strong point. In the past I've learnt languages through necessity but I don't usually find myself in situations where neither C# or JavaScript will do the job.

I decided to learn F# by solving mathematical puzzles. To that end I've found a number of suitable puzzles, the first of which can be found here.

The first of the problems listed at Foo Hack is called 'Square the Sum', it is this puzzle that is the subject of this post. I won't describe the problem here, for more information see the original post at Foo Hack. What I will describe are the challenges I faced while devising the solution.

As my first attempt at writing anything significant in F#, I felt like a fish out of water. I was unsure how to layer multiple steps within a single function, my head was swimming with features (I'd yet to try in C#) like anonymous methods and lambda expressions, that I knew had there roots in languages like F#. The mist cleared when I understood that all functions in F# are essentially single parameter functions. Functions that appear to have multiple parameters are actually curried, each parameter is parsed by a function generated by the function that parsed the previous parameter. I hope that makes sense, it took me a little while to get my head around it. The concept is best explained at Inside F#.

With this point explained, the idea of layering multiple functions on top of each other is easier to swallow. I believe the pipeline operator can be used to do something similar, but I've not touched on that yet. I now have a function called sqSum that performs all the steps required to split x in half, add those halves together and square the total. Now I need to iterate through a range of integers and identify those that match the criteria as laid out in the original problem. This functionality was provided in the form of List.filter. List is part of the FSharp.Collections namespace, the filter function allows you create a collection based on the condition set in your anonymous function, in this case when the result of sqSum equals the original figure.

My last hurdle was the dynamic typing performed by F#. In C# I'm used to strongly typing everything, in JavaScript I'm used checking whenever possible. After a few implicit conversion errors I soon remembered when to decimalise and explicitly type.

My solution is below:

let sqSum x : float =
 let top = round (x / 1000.00)
 let bot = x - (top * 1000.00)
 let tot = top + bot
 tot * tot

let lst = List.filter (fun x -> float x = sqSum (float x)) [100000 .. 999999]

Which returns:


[494209; 998001]

I'm sure there are a myriad of ways in which you can come to this solution, what I'd be interested in is some insight into the efficiency of my solution and how it might bettered. This is a learning exercise after all.

Date Support For Ajax Dot Net Plugin

2008-07-25T20:23:00.003+01:00

The Ajax Dot Net jQuery plugin now returns native JavaScript Date objects.

Details here.

School Boy

2008-07-14T21:39:00.004+01:00

ASP.NET jQuery Plugin

2008-07-09T13:16:00.002+01:00

Following my previous post on communicating with ASP.NET Ajax enabled Web Services and PageMethods. I have encapsulated the code in a jQuery Plugin.

Details can be found here.

Graceful Lists

2008-06-27T14:51:00.008+01:00

In a project I was working on recently I needed to return a list. I can't remember what the list consisted of (okay not that recent), but each item in the list was going to require some processor power to generate the item's associated content. I didn't want to take the standard server side approach of building the list prior to rendering the page. While the list size was fixed, the processing time for each item varied, making timeouts a factor. The age of the data was also important, preventing the possibility of server side caching over any length of time.

The proposition I came up with is not an uncommon one. The idea was to create a page which loaded each item on the list incrementally using XHR. But what about browsers without JavaScript or with JavaScript switch off? Initially, I considered drastically reducing the amount of results returned by the page using paging. My main concern here was that while you can generally tell whether the user's browser is JavaScript enabled from the User Agent, it's impossible (as far as I'm aware) to detect whether the user has opted to disable JavaScript, on the first request to the server. Also, paging drives me nuts, I prefer to scroll!

I had assumed browsers broadcasted the status of scripting abilities and alike in the header of each request. I have no reason for assuming this, other than it sounds like quite a good idea to me.

Without being able to reliably detect a browser's scripting ability, the paging solution risks serving an empty page to browsers with JavaScript disabled. While investigating this problem I came across 123-reg.co.uk. 123-reg.co.uk uses a similar pattern to the one I've suggested, for displaying domain availability. User's with JavaScript enabled browsers see the list built in front of them using Ajax. Everyone else is served a pre-rendered list. What is clever (in its simplicity) is the way in which 123-reg.co.uk detects JavaScript. On the page where the user enters their search terms, a script modifies the action URL of the form to include the parameter "ajax_enabled=true". The results page is rendered based on the value of that parameter.

The example provided by 123-reg.co.uk is a great way of detecting script. The problem with this approach is the reliance on the search page (to modify the URL), my list exists on a page that is a possible entry point to the application. I'm not making it easy for myself. As a result of the previous example I also toyed with the idea of a page that assumes JavaScript is switched on, but with a META Refresh tag in the header. If JavaScript is enabled, remove the META tag. If JavaScript is disabled, the page redirects (via the META tag) to a pre-rendered page. I was put off by the idea of effectively breaking the Back button for users without JavaScript.

My eventual implementation was a pre-rendered list that assumed JavaScript was switched off. This list doesn't contain any of the extended content, so no heavy lifting that originally had me concerned. Each item on the list instead provides anchors to a second page that generates the extended content. Once the page is loaded, JavaScript enabled browsers move though each of the items, dynamically adding the extend content. This solution works extremely well for script enabled browsers, everything on one page with visual feedback for the processing going on server side. Unscripted browsers have the burden of an extra click to and from the extended content, but the initial page load dramatically reduced when compared to the server side approach described at the beginning of this post.

This particular problem made me think a lot about my audience and the merits of graceful degradation. Who am I making this application for? And more importantly, who am I willing to exclude? Within a corporate Intranet, these decisions are sometimes made by company guidelines and policies, a lot of the time by time constraints. In the open web, (I believe) accessibility is extremely important. If you are building something like Facebook, where you a targeting a market defined by age, gender or interest, your application should be accessible to text readers and main stream browsers alike. The experience has also showed me that I'm not so bothered about catering for users that have purposefully restricted the capability of their own browser (switching off script or CSS). I guess there might be a valid reason for doing this, but I'm unable to come up with one.

Bridging ASP.NET & jQuery

2008-06-21T14:40:00.023+01:00

Until recently I was inclined to use the ASP.NET AJAX framework when working with JavaScript within Visual Studio, if I used a library at all. I hadn't really been sold on the idea of JavaScript frameworks or libraries from the get go. I realise this sounds a bit ridiculous coming from an ASP.NET developer, but I enjoy writing JavaScript and saw these libraries as taking some of the fun out of it.

I eventually saw the benefits of a library when I started playing around with the wicked cool JavaScript intellisence and debugging support in Visual Studio 2008. Still, it was a mixed bag. I enjoyed the short cuts and the object descriptor’s provided through the script manager but was wary of the amount of JavaScript being generated in the background. I was also very conscious that, at least in my opinion, this library was built for developers who don't enjoy working with the client, in fact providing a level of abstraction such that the developer doesn't need to touch the client at all. For that last concern I found jQuery. jQuery isn’t just about creating short cuts around well trodden problems, jQuery enables you to work in an entirely more intuitive way. Thank you John Resig.

So now I have two libraries, I was torn. If I wanted to make use of ASP.NET great JSON web services I had to use the Microsoft library. If I wanted to do anything else I was using jQuery. It’s all sounding a bit bloated.

That was until I read a fantastic article @ Encosia called 3 mistakes to avoid when using jQuery with ASP.NET AJAX. In the article, Dave Ward explains the connection between the ASP.NET JSON Page Method and the client side AJAX library. What had never occurred to me and what Dave pointed out was that client and the server were not inseparable. In fact you can talk quite happily with your JSON enabled Page Methods and Web Services with jQuery alone.

"Great", I thought. "This is it!" I said. I started writing Ajax calls in the way Dave described, thrilled by the possibilities that laid before me. FireFox loved it, FireBug reported all's well. IE was not having it. "Aw", I thought. "Aw dear." I said. You can read up on the trials and tribulations of talking to an ASP.NET JSON Page Method on the Encosia blog, needless to say I experienced these and more. Once I had Page Methods working I had more problems with Web Services.

I should mention at this point that most of these problems arose from false assumptions on my part about certain aspects of the code, specifically the need to stringify the data parameter.

My conclusion was that the requirements of these calls were a bit too specific for jQuery's ajax function. So to the point of my post, I have written a very simple function that works much like jQuery's ajax method but is designed solely to work with ASP.NET JSON Page Methods and Web Services. I've namespace'd it to avoid collisions with other frameworks and I believe the scripts only external dependency is on that of json2.js from json.org.

/// <reference path="jquery-1.2.6.min.js">
/// <reference path="json2.js">

var k3r = new Object();
k3r.ajax = function() {}
k3r.ajax.xhr = function() {
 try { return new XMLHttpRequest(); } catch(e) {}
 try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) {}
 try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) {}
 return null;
}

k3r.ajax.request = function(obj) {
 var xhr = k3r.ajax.xhr();
 var loc = obj.location;
 var data = '';

 if (obj.type == 'GET') {
  for (var i in obj.pack) {
   if (data != '')
    data += '&';
    data += i + '=' + obj.pack[i];
  }
  loc += '?' + data;
  data = null;
 }
 else if (obj.type == 'POST') {
  data = JSON.stringify(obj.pack);
 }

 xhr.open(obj.type, loc, true); //true = async
 xhr.onreadystatechange = function() {
  if (xhr.readyState == 4) {
   var response;
   try {
    response = JSON.parse(xhr.responseText);
   }
   catch (err) {
    response = err;
   }

   if (xhr.status == 200 && typeof obj.success != 'undefined')
    obj.success(response, xhr.status, xhr.statusText);
   else if (typeof obj.other != 'undefined')
    obj.other(response, xhr.status, xhr.statusText);
  }
 }

 xhr.setRequestHeader("Content-Type", "application/json; charset=utf-8");
 xhr.send(data);
}

The method k3r.ajax.request takes an object containing 5 parameters; 'type', 'pack', 'location', 'success' and 'other'.

type: The verb associated with the request. Only GET & POST are currently catered for.
pack: A JSON object containing the input parameters.
location: The URL of the web service method.
success: Callback function if request is successful. JSON returned.
other: Catch-all callback function for everything else. Error message returned.

An example request would look like this:

k3r.ajax.request({
 type: 'GET',
 pack: {id: 1},
 location: 'Example.aspx/GetExample',
 success: function(obj) {
  console.info(obj); //FireBug required;
 },
 other: function() {
 }
});

The benefits of k3r.ajax.request over the jQuery ajax function, when looking at ASP.NET JSON Web Services specifically, are as follows:

You can pass the input parameters as a JSON object, no need to stringify.
The IE Content-Type strangeness is taken care of behind the scenes.
k3r.ajax.request is not dependant on jQuery, it should work with any library.
Should work with JSON enabled ASP.NET Page Methods and Web Services straight out of the box.

What comes next? When I have the time I'd like to explore the possibility of adding this and other ASP.NET helpers into a jQuery plugin. Also, I'm certain there is some room for improvement with my error handling.