Foliotek Developer Blog

bindWithDelay jQuery Plugin

Sometimes, I want to have a JavaScript event that doesn’t fire until the native event stops firing for a short timeout. I’ve needed to use that pattern in almost every project I have worked on.

For example, you want to use JavaScript to resize an iframe to 100% height when the window resizes. The resize() event can fire dozens of times, and calculating and setting the new height can slow down your page. I used to implement it like this:

[sourcecode lang="javascript"]
var timeout;
function doResize(e) {
clearTimeout(timeout);
timeout = setTimeout(function() {
// run some code
}, 200);
}
$(function() {
$(window).bind(“resize”,doResize);
});
[/sourcecode]

Notice that there are extra variables that you have to deal with, and extra indentation. You could at least clean up the global variable using closures, but you get the idea.

I wrote a plugin to make this pattern easier, it is called “bindWithDelay”. The source code is online, as is a mini project page with a demo.

This is what the same code looks like with the plugin:

[sourcecode lang="javascript"]
function doResize(e) {
// run some code
}
$(function() {
$(window).bindWithDelay(“resize”, doResize, 200);
})
[/sourcecode]


Handy ASP.NET Debug Extension Method

Most of the programmers I know (myself included) don’t bother with the built in Visual Studio debugging tools. They are slow and resource intensive. Usually, its more efficient to just do one or more Response.Write calls to see key data at key steps.

That can be a hassle, though. Most objects don’t print very well. You have to create a loop or write some LINQ/String.Join to write items in a collection.

Inspiration struck – couldn’t I write an extension method on object to write out a reasonable representation of pretty much anything? I could write out html tables for lists with columns for properties, etc.

Then I thought – I love the javascript debug console in firebug. I can drill down into individual items without being overwhelmed by all of the data at once. Why not have my debug information spit out javascript to write to the debug console? That also keeps it out of the way of the rest of the interface.

Here’s the code:

[sourcecode lang="csharp"] public static void Debug(this object value) { if (HttpContext.Current != null) { HttpContext.Current.Response.Debug(value); } } public static void Debug(this HttpResponse Response, params object[] args) { new HttpResponseWrapper(Response).Debug(args); } public static void Debug(this HttpResponseBase Response, params object[] args) { ((HttpResponseWrapper)Response).Debug(args); } public static void Debug(this HttpResponseWrapper Response, params object[] args) { if (Response != null && Response.ContentType == "text/html") { Response.Write("

This function allows access to server controls without adding additional markup and without the JavaScript existing on the .aspx page.

  • Note: There is a potential limitation if you had one control with the ID="txtPhoneNumber" and another with ID="mytxtPhoneNumber". Both elements end with "txtPhoneNumber" and the selector would not necessarily return the correct value. This solution is not perfect in that sense, but the benefits it provides over other methods (cleaner markup and ability to use external JavaScript files) make it a good alternative.