Fire an event using JQuery with a delay

Sometimes when you're building some javascript to validate a field, you don't necessarily want that field to be constantly re-evaluated. An example of this is when you're validating a password. You want to make sure that the password is valid after the user's finished entering it, but you don't really want them to have to click a 'validate' button. Wouldn't it be neater if it just evaluated it 'on the fly'? Most password validation tools also have a nice progress bar that changes colour when you start producing more sensible passwords, going from scary red to calming green. If your bar changed colour after every key press, it'd become a quite cumbersome and CPU-intensive process. This is where bindWithDelay comes in! Using this example, the registered event will wait until the user lifts their finger and does nothing further within this field for one second prior to running the password validation function. This super-handy little plugin is available courtesy of http://briangrinstead.com.

Using SignalR and MVC to create a Facebook style news feed

A thought occurred to me whilst driving home a few days ago, where I considered that there was a buzz around node.js and servers pushing content directly to clients. The connecting thought was that I had no idea how this could be accomplished using the .NET framework.

I decided that I'd be really interested to find out if it would be possible to use .NET to produce a Facebook-style news feed that automatically refreshes as soon as something is pushed to the list. Podio does a really good job of this too. As soon as a user posts an update on a story, the change is immediately pushed to all clients complete with a snazzy "knock-knock" sound effect.

There are a few ways of accomplishing this using standard AJAX. The first is long-polling, which maintains an open connection waiting for the server to send something when it's ready. The second way of doing this is using the Javascript setInterval function to poll the server and see if anything has changed every x number of seconds.

However, I wanted a Websockets-style solution that would manage connections better. I did a bit of reading around the subject, and arrived at SignalR.

The clever bit about SignalR is that it provides all the support for this sort of connection for you. It starts by trying a WebSockets connection, and if your browser (or the webserver for that matter) doesn't support it, it picks a different method of transport until it finds something that fits. For Chrome and IIS 8 it would be WebSockets, and for any Internet Explorer version, it uses Forever Frame. You can read more about that on this StackOverflow answer from one of the authors.

My plan was this. I would produce a simple MVC application with a standard create form with two fields. Name and update type (either news or event). When the MVC submission was complete, the update would appear in all connected browsers, almost like a one-way multicast chat program, but over HTTP instead of a standard socket.

I then wanted a bit of JQuery in place that would push the list down and fade my new update in at the top of the list, because the list is ordered by publish date.

I created a blank MVC project, and created a controller class with skeleton actions for index and create. My view contained references to JQuery, JQuery UI, the SignalR Javascript includes, and the standard rendering of the existing list.

To prevent any confusion of the point of the project, this example doesn't connect to a database. I create a list of existing news and event updates in global.asax.cs, and store them in the HttpContext.Application object.

I then needed to create a Hub class that my client would connect to in order to receive updates. If you want the client to fire methods on the server-side, you can create them in this hub class. In my case however, I'm just pushing content from the server to the client, and this is done later on in my controller class.

My controller class takes the name and type of update, and adds it to the list of updates in the Application state as any MVC application would do. The difference however, is just before returning the view, I call a new function called SendMessage(Update). It looks like this:


The idea of a lot of SignalR examples is to push client events to the server, which then distributes it to all clients. I didn't want client-side code muddying the waters of submission of simple data, because in the future, data may change in a different way.

For example, we may want to create a delegate method server-side that performs some functionality and then pushes updates to the clients, rather than waiting for client input. My example is broadcasting a server-side event to all connected clients. This is all happening in BroadcastUpdate using .NET 4.0 dynamic variables to call client functionality.

The last step was to implement some Javascript that would listen on a connection for a call from the server to a client-side method. When this response is sent over, we get a serialized JSON object containing our update. We then do a bit of nifty JQuery to make it fade into appearance at the top of the list.

The Javascript looks like this:


It's really best to get the source code and see the demo in action to really understand how it all fits together, so I've uploaded the project to a repository on GitHub so that you can get it running yourselves.

I understood much more about how to use SignalR in this video about SignalR.

JQuery.Cycle messes up on DOM ready

I had a bug recently when using JQuery.Cycle for a slideshow with large images.

The cycle method fails on page load when the images aren't cached.

This was because I was using:
$("document").ready(function() {
    // code here
});

Instead of that, if you use:
$(window).load(function() {
    // code here
});

Your content will load prior to the cycle method being executed.

See this Stack Overflow article for the full explanation:
JQuery cycle fails on page refresh

Element.setAttribute and other strange problems

Heed this.

If you're using javascript events like onmouseover and onmouseout, don't bother using them if you want to do something clever.

My plan for these events was as follows:

• Your image has an onmouseover and onmouseout state. An on / off state.
• When clicking this image, the onmouseover and onmouseout state change. So does the source of the image.

The trouble with this is that if you want to modify the onmouseover and onmouseout events dynamically in a javascript function depending on whether the image has been clicked or not, you're out of luck. Firefox supports the element.setAttribute('attribute','property') method, but Internet Explorer versions do not.

Even what Firefox does support seems to be patchy, and doesn't complete my image swapping. The event states didn't want to stick across browser versions.

It turns out that if you want to alter those mouse-related events, you can't do it dynamically in a javascript function. IE won't let you at all, and Firefox's support seems to be buggy.

So how did I get around this?

Our creative girl produced a cascading stylesheet which had images with on/off states in them, and then moved the image depending on what the class of the div surrounding our image was. From there, we could alter the class of the div and therefore alter the hover states.

For example:

Price

Where price_result1 in the stylesheet is:

.price_result1 {
width:44px;
height:12px;
background:url(../images/result_headers/price.gif);
float:left;
}

.price_result1 a {
display:block;
width:44px;
height:12px;
background:url(../images/result_headers/price.gif) 0% 0% no-repeat;
}
.price_result1 a:hover {background-position:0% 75%;}

price_result2 is:

.price_result2 {
width:44px;
height:12px;
background:url(../images/result_headers/price.gif) 0% 75% no-repeat;
float:left;
}
.price_result2 a {
display:block;
width:44px;
height:12px;
background:url(../images/result_headers/price.gif) 0% 75% no-repeat;
}
.price_result2 a:hover {background-position:0% 100%;}





And so on.

I hope this helps. Really I do, because it took me three days to work this out.

The XMLHttpRequest object

This is AJAX related, and likely to cause problems if you're doing what I'm doing.

I use the object to write out some HTML into a div of a page.

The HTML I'm writing is from an ASP file, and so the syntax for the (pre-declared object) looks like this:

url = "searchDBaseAjax.asp?" + savedUrl;
url=url+"&sid="+ Math.random();

xmlHttp.onreadystatechange=caravanSearchStateChanged;
xmlHttp.open("GET",url,true);
xmlHttp.send(null);


Now if youre searchDBaseAjax.asp file contains some javascript that you want to write to that div, and you want it to happen straight away, you'll have problems.

Say you put a hidden input field in your ASP file.

Say that you then want to test this within the function that you write your ASP file from (just below the code mentioned above).

if (document.getElementById('hideHeaders').value == '1') {
document.getElementById('resultsHeader').className = ' none';
}
else {
document.getElementById('resultsHeader').className = 'floatleft paddingtop15';
}

Because this is an asynchronous call, it's likely that the processing of the AJAX method will not be completed by the time that your javascript underneath executes, and therefore your input field will not be tested properly.

One solution was to make this method synchronous. (Change the true in the open method to false). Trouble is, that doesn't work.

So to fix it, I used the xmlHttp.onreadystatechange attribute to specify the method caravanSearchStateChanged which is mentioned in the first code-snippet.

That method now looks like this:

function caravanSearchStateChanged()
{
if (xmlHttp.readyState==4)
{
document.getElementById("ajaxSearchResults").innerHTML=xmlHttp.responseText;

if (document.getElementById('hideHeaders').value == '1') {
document.getElementById('resultsHeader').className = ' none';
}
else {
document.getElementById('resultsHeader').className = 'floatleft paddingtop15';
}
}
}

So basically, the ready state for our open method is 4 and I've checked that this is the case before I fire off my new javascript that tests the input field.

Days of messing about, this took.

For more information, check out the MSDN entry.