Skip to main content

3 posts tagged with "microsoft"

View All Tags

A Potted History of using Ajax (on the Microsoft Stack of Love)

This post originally started out as an explanation of JSON. However as I wrote this quickly got abandoned in favour of writing about how I came to use JSON in the first place - which was through the use of Ajax. Having written a goodly amount I've now decided to move the actual JSON stuff into another post since I think Ajax is probably worth thinking about by itself rather than as an aside. So let me start at the beginning and explain how I came to use Ajax in the first place (this may take some time so please bear with me). In late 2004 I first started working on a project which I was to remain involved with (on and off) for a very long time indeed. The project was part financial reporting system and part sales incentivisation tool; it was used internally in the investment bank in which I was working. The project had been in existence for a number of years and had a web front end which at that point would been built in a combination of HTML, JavaScript, classic ASP and with a Visual Basic 6.0 back end. One of the reasons I had been brought on to the project was to help ".Net-ify" the thing and migrate it to ASP.NET and C#. I digress. The interesting thing about this app was that there were actually some quite advanced things being done with it (despite the classic ASP / VB). The users could enter trades into the system which represented actual trades that had been entered into a trading system elsewhere in the organisation. These trades would be assigned a reporting value which would be based on their various attributes. (Stay with me people this will get more interesting I *promise*.) The calculation of the reporting value was quite an in depth process and needed to be performed server-side. However, the users had decreed that it wasn't acceptable to do a full postback to the server to perform this calculation; they wanted it done "on-the-fly". Now if you asked me at the time I'd have said "can't be done". Fortunately the other people working on the project then weren't nearly so defeatist. Instead they went away and found Microsoft's webservice.htc library. For those of you that don't know this was a JavaScript library that Microsoft came up with to enable the access of Web Services on the client. Given that it was designed to work with IE 5 I suspect it was created between 1999-2001 (but I'm not certain about that). Now it came as a revelation to me but this was a JavaScript library that talked to our web services through the medium of XML. In short it was my first encounter with anything remotely Ajax-y. It was exciting! However, the possibilities of what we could do didn't actually become apparent to me for some years. It's worth saying that the way we were using webservice.htc was exceedingly simplistic and rather than investigating further I took the limited ways we were using it as indications of the limitations of Ajax and / or webservice.htc. So for a long time I thought the following: - The only way to pass multiple arguments to a web service was to package up arguments into a single string with delimiters which you could split and unpackage as your first step on the server.

  • The only valid return type was a single string. And so if you wanted to return a number of numeric values (as we did) the only way to do this was to package up return values into a very long string with delimiters in and (you guessed it!) split and unpackage as your first step on the client.
  • The only thing that you could (or would want to) send back and forth between client and server was XML

So to recap, I'm now aware that it's possible for JavaScript to interact with the server through the use of web services. It's possible, but ugly, not that quick and requires an awful lot of manual serialization / deserialization operations. It's clearly powerful but not much fun at all. And that's where I left it for a number of years. Let's fade to black... It's now 2007 and Microsoft have released ASP.NET Ajax, the details of which are well explained in this article (which I have only recently discovered). Now I'm always interested in "the new" and so I was naturally interested in this. Just to be completely upfront about this I should confess that when I first discovered ASP.NET Ajax I didn't clock the power of it at all. Initially I just switched over from using webservice.htc to ASP.NET Ajax. This alone gave us a *massive* performance improvement (I know it was massive since we actually received a "well done" email from our users which is testament to the difference it was making to their experience of the system). But we were still performing our manual serialisation / deserialisation of values on the client and the server. ie. Using Ajax was now much faster but still not too much fun. Let's jump forward in time again to around 2010 to the point in time when I was discovering jQuery and that JavaScript wasn't actually evil. It's not unusual for me to play around with "what if" scenarios in my code, just to see what might might be possible. Sometimes I discover things. So it was with JSON. We had a web service in the system that allowed us to look up a counterparty (ie a bank account) with an identifier. Once we looked it up we packaged up the counterparty details (eg name, location etc) into a big long string with delimiters and sent it back to client. One day I decided to change the return type on the web service from a string to the actual counterparty class. So we went from something like this: ```cs [WebService(Namespace = "http://tempuri.org/")][WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] [ScriptService] public class CounterpartyWebService : System.Web.Services.WebService { [WebMethod] public string GetCounterparty(string parameters) { string[] aParameters = parameters.Split("|"); int counterpartyId = int.Parse(aParameters[0]); bool includeLocation = (aParameters[1] == "1"); Counterparty counterparty = _counterpartyDb .GetCounterparty(counterpartyId);

string returnValue = counterparty.Id +
"|" + counterparty.Name +
(includeLocation
? "|" + counterparty.Location
: "");
return returnValue;

} }

To something like this: ```cs
[WebMethod]
public Counterparty GetCounterparty(string parameters)
{
string[] aParameters = parameters.Split("|");
int counterpartyId = int.Parse(aParameters[0]);
bool includeLocation = (aParameters[1] == "1");
Counterparty counterparty = _counterpartyDb
.GetCounterparty(counterpartyId);
return counterparty;
}

I genuinely expected that this was just going to break. It didn't. Suddenly on the client I'm sat there with a full blown object that looks just like the object I had on the server. WHAT BLACK MAGIC COULD THIS BE?????????? Certain that I'd discovered witchcraft I decided to try something else. What would happen if I changed the signature on the method so it received individual parameters and passed my individual parameters to the web service instead of packaging them up into a string? I tried this: ```cs [WebMethod] public Counterparty GetCounterparty(int counterpartyId, bool includeLocation) { Counterparty counterparty = _counterpartyDb .GetCounterparty(counterpartyId);

return counterparty; }

And it worked! **[IT WORKED!!!!!!!!!!!!!!!!!!!!!](<http://www.youtube.com/watch?v=N_dWpCy8rdc&feature=related>)** (And yes I know I wasn't actually using the includeLocation parameter - but the point was it was being passed to the server and I could have used it if I'd wanted to.) I couldn't believe it. For **years** I'd been using Ajax and without **any** idea of the power available to me. The ignorance! The stupidity of the man! To my complete surprise it turned out that: - Ajax could be quick! ASP.NET Ajax was lightening fast when compared to webservice.htc
- You could send multiple arguments to a web service without all that packaging nonsense
- You could return complex objects without the need for packaging it all up yourself.
<!-- -->
Essentially the source of all this goodness was the magic of JSON. I wouldn't really come to comprehend this until I moved away from using the ASP.NET Ajax client libraries in favour of using the [jQuery.ajax](<http://api.jquery.com/jQuery.ajax/>) functionality. (Yes, having mostly rattled on about using webservice.htc and ASP.NET Ajax I should clarify that I have now forsaken both for jQuery as I find it more powerful and more configurable - but it's the journey that counts I guess!) It's abysmal that I didn't discover the power of Ajax sooner but the difference this discovery made to me was immense. Approaches that I would have dismissed or shied away from previously because of the amount of "plumbing" involved now became easy. This massively contributed to my [programmer joy](<http://www.hanselman.com/blog/HanselminutesPodcast260NETAPIDesignThatOptimizesForProgrammerJoyWithJonathanCarter.aspx>)! Next time I promise I'll aim to actually get onto JSON.

What on earth is jQuery? And why should I care?

What on earth is jQuery? What's a jQuery plugin?

These were the questions I was asking myself shortly after discovering that jqGrid was a "jQuery plugin". I'd been vaguely aware of the phrase "jQuery" being increasingly mentioned on various techical websites since about 2009. But for some reason I'd felt no urge to find out what it was. I seem to remember that I read the name "jQuery" and jumped to the perfectly logical (in my head) conclusion that this must be a Java SQL engine of some sort. (After all "j" as a prefix to anything so far had generally been Java and "Query" just rang of databases to me.) Clearly I was wrong - life's full of surprises.

I soon discovered that, contrary to expectations, jQuery had nothing to do with Java *and* nothing to do with databases either. It was in fact a JavaScript library written by the amazing John Resig. At the time I had no love for JavaScript. I now realise I knew nearly nothing about it but my feeling was that JavaScript was awful - evil even. However, given JavaScripts ubiquity in the world of web it seemed to be a necessary evil.

I took a look at the jQuery website and after reading round a bit I noticed that it could be used for Ajax operations. This lead to me reaching the (incorrect) conclusion that jQuery was basically an alternative to the Microsoft Ajax library which we were already using to call various Web Services. But I remained frankly suspicious of jQuery. What was the point of this library? Why did it exist?

I read the the blog by Scott Gu announcing Microsoft was going to start shipping jQuery with Visual Studio. The Great Gu trusted it. Therefore, I figured, it must be okay... Right?

The thing was, I was quite happy with the Microsoft Ajax library. I was familiar with it. It worked. Why switch? I saw the various operations Scott Gu was doing to divs on the screen using jQuery. I didn't want to do anything like that at all. As I said; I had no love for JavaScript - I viewed it as C#'s simple-minded idiot cousin. My unofficial motto when doing web stuff was "wherever possible, do it on the server".

I think I would have ignored jQuery entirely but for the fact of jqGrid. If I wanted to use jqGrid I had to use jQuery as well. In the end I decided I'd allow it house room just for the sake of jqGrid and I'd just ignore it apart from that. And that's how it was for a while.

Then I had an epiphany. Okay - that's overplaying it. What actually happened was I realised that something we were doing elsewhere could be done faster and easier with jQuery. It's something so ridiculously feeble that I feel vaguely embarrassed sharing it. Anyway.

So, you know the css hover behaviour is only implemented for anchor tags in IE6? No? Well read this Stack Overflow entry - it'll clarify. Well, the app that I was working on was an internal web application only used by people with the corporate installation of IE 6 on their desktops. And it was "terribly important" that buttons had hover behaviour. For reasons that now escape me we were doing this by manually adding inline onmouseover / onmouseout event handlers to each input button on the screen in turn in every page in the Page_Load event server side. I think we were aware it wasn't fantastic to have to wire up each button in turn. But it worked and as with so many development situations we had other pressures, other requirements to fulfil and other fish to fry - so we left it at that.

And then it occurred to me... What about using the jQuery class selector in conjunction with the jQuery hover event? I could have one method that I called on a page which would wire up all of my hover behaviours in one fell swoop. I wouldn't need to do input-by-input wireups anymore! Hallelujah! This is what I did:

The buttons I would like to style:

<input type="button" value="I am a button" class="itIsAButton" />
<input type="button" value="So am I" class="itIsAButton" />
<input type="button" value="Me too" class="itIsAButton" />

My CSS (filter, by the way, is just linear gradients in IE 6-9):

.itIsAButton
{
filter:progid:DXImageTransform.Microsoft.Gradient (GradientType=0,StartColorStr='#ededed',EndColorStr='#cdcdcd');
}
.itIsAButton:hover, .itIsAButton_hover /* "_hover" is for IE6 */
{
filter:progid:DXImageTransform.Microsoft.Gradient (GradientType=0,StartColorStr='#f6f6f6',EndColorStr='#efefef');
}

My jQuery:

$(document).ready(function () {
//Add hover behaviour on picker buttons for IE6
if (($.browser.msie) &&
(parseInt($.browser.version, 10) < 7)) {
var fnButtonHover = function (handlerInOut) {
var $btn = $(this);
var sOriginalClass = $btn.prop("class");
if (handlerInOut.type === "mouseenter") {
//If not already hovering class then apply it
if (sOriginalClass.indexOf("_hover") === -1) {
$btn.prop("class", sOriginalClass + "_hover");
}
}
else if (handlerInOut.type === "mouseleave") {
//If not already non-hovering class then apply it
if (sOriginalClass.indexOf("_hover") !== -1) {
$btn.prop("class", sOriginalClass.split("_")[0]);
}
}
};
$(".itIsAButton").hover(fnButtonHover);
}
});

And it worked. I didn't really understand this much about this jQuery "thing" at that point but I could now see that it clearly had at least one use. I've come to appreciate that jQuery is one of the best pieces of software I've ever encountered. Over time I may go further into some of the good stuff of jQuery. It is, quite simply, brilliant.

Standing on the Shoulders of Giants...

It started with Scott Hanselman. I had no particular plans to start a blog at all. However, I was reading Scott Hanselman's turn of the year post and I was struck with an idea.

First, let me give a little background about myself. I'm a software developer. I've been in the industry for coming up to 15 years. I started out professionally writing call centre software. I moved on to code in a variety of different industries from straight IT to marketing and, for the last 7 years, finance.

Though I initially started out writing in Delphi I fast found myself moving toward the Microsoft "stack of love". I should say that this move was not because I instinctively liked Microsofts stuff (in fact in the beginning I actively disliked it - moving from Delphi 3.0 to Visual Studio 5 left me finding Microsoft's offering very much wanting). Rather it was pragmatic. I needed a job and at the time VB was a far more transferable skill than Delphi. What with the all encompassing dot-com bubble of the late 90's I soon found myself working in the webtastic world of classic ASP (weep) and VB server components (remember them?).

Though things can improve - and in my opinion they really did when Microsoft coughed up the first furball of ASP.NET Beta in (I think) 2001. I grabbed on with both hands. Since that point I've been earning my bread pretty much, though not exclusively, in the ASP.NET universe.

The one thing that might not be clear from the above curriculum vitae is this: I AM A COMPLETE AMATEUR. I mean this in both senses of the word:

  1. I have no formal training to speak of - I didn't do a computer sciences degree. In fact my first real coding experience was writing a program in Locomotive Basic for my father on our humble Amstrad CPC.
  2. That said, I love it. I find writing code an intellectually, emotionally, creatively satisfying act. And whilst I undoubtedly have less of the theoretical knowledge which most professional developers seem to have, I probably counter-balance that with a hunger to keep learning and keep trying new things. And since software never sits still that's probably just as well. Keep watching the horizon - there will be something coming over it! And it's worth saying, I have an instinct for developing which serves me pretty well. I'm good at coming up with elegant and pragmatic solutions. Put simply: I'm good at making code work.

So back to the point. In my daily work life, like any other developer, I am repeatedly called on to turn someones requirement into a reality. Very rarely do I achieve this on my own. Like most of us I'm a dwarf standing on the shoulders of giants. There's a lot of people out there who come up with useful tools / components / plug-ins that make it possible for me to deliver much more than I would given my own abilities.

So that's what I want to do: I want to talk about the tools, components and techniques that I have found useful in the everyday working life of a developer. It's likely to be quite a "webby" blog as I probably find that the most interesting area of development at the moment.

I don't know how often I will write but my plan is that when I do, each time I'll talk about something I've found useful - why I found it useful, what problems it solved, what issues it still presented me with and so on. This is probably not going to be a "techie techie" blog. Rather a blog that deals with the situations that can confront a developer and how I've responded to them. I hope you find it interesting. And if you don't; please keep it to yourself :-)