Hey Dave, is there a way to create an event handler so when .tmpl() is done it will fire a function? I’m trying to make it global, so I was hoping I could say, when ANY template gets done, do this…

The question of how to retroactively add hooks before and/or after a pre-existing JavaScript function executes is one that comes up from time to time. Whether it’s a simple method like tmpl(), a server-generated script artifact, or a function in a third-party script, sometimes it’s desirable to alter a JavaScript function without access to change the original declaration of the function.

One of the handy things about JavaScript is that you can combine its functional and dynamic aspects to make surprisingly quick work of tasks like this one. Doing so is fairly straightforward, but it involves an approach you might not consider if you’re more familiar with languages that lack JavaScript’s unique features.

In this post, I’ll briefly cover a few examples of how to “patch” existing JavaScript functions with callbacks. We’ll begin with simple examples, then address an issue that stems from applying this approach to jQuery plugins, and finish with a more elegant way to handle the problem of patching functions that accept parameters.

Click here to read the rest of this post »

If you’re like me, HTTP status code 200 Object] unknown probably doesn’t ring any bells. Of course, that’s mainly because it doesn’t exist.

So, how did I end up with the screenshot above? I’ve been running with scissors again. It was one of the more popular web frameworks for Node.js that I cut myself with this time: Express.js

Unfortunately, a malformed status code like 200 Object] will cause some browsers (including the version of Chrome I was using at the time) to refuse loading the page at all. That quickly elevated the importance of my strange status code from a trivial oddity to an annoying thorn in the side.

As it turns out, my code was running up against a documented Express feature and the remedy was simple enough.

Click here to read the rest of this post »

I’ve been experimenting with Tomasz Janczuk’s awesome iisnode project lately, in hopes of hosting some of my Node.js sites on IIS. Those sites are running well enough on an Ubuntu VPS currently, but the features that iisnode offers are compelling (and I have unused capacity on one of my Windows servers).

Along the way, I ran into one issue that isn’t addressed in the current iisnode documentation or examples very well. If you try to set up a standalone Node.js website in IIS you’re likely to be greeted with this error when you load it up for the first time:

Remotely, you’ll see the dreaded “The service is unavailable.” error:

Those nondescript errors don’t exactly make resolving the problem very straightforward. So, I want to recap what I found to be the underlying problem in my case and a few solutions, in hopes of helping anyone else that ends up with the same issue.

Click here to read the rest of this post »

Over the past several months, I’ve been participating as an adviser to an interesting Microsoft patterns & practices effort named Project Silk. I don’t publish posts here about every project I’m tangentially involved in, but I think Project Silk is worth a look if you’re building modern, JavaScript-heavy web applications.

The project itself is comprised of a complete reference application and an extensive set of documentation describing how the app works and the process behind the design decisions that the team made along the way. Think of it as the NerdDinner sample (and accompanying book chatper), but focused almost entirely on client-side development rather than the server-side MVC component.

One of the most valuable aspects of the project is that it takes aim at the almost intractable topic of building large, maintainable JavaScript applications. You can see how seriously they took that goal by the time you get to just the second paragraph of the project summary:

Click here to read the rest of this post »

With the confusion surrounding jQuery 1.6′s changes to .attr() and the addition of .prop(), one of my favorite new features nearly slipped under the radar. The feature I’m referring to is that $.map() now works against plain JavaScript objects in addition to arrays.

$.map() has always been a useful utility method, somewhat mimicking ECMAScript 5′s native Array.map() method. If you’ve been working with JavaScript long, you’re probably already comfortable with passing anonymous function callbacks around anyway, which makes higher order functions like map an intuitive way to write concise, expressive transformation code.

With jQuery 1.6, now you can use the same approach when working with regular JavaScript objects. There are a variety of uses for this, but I want to focus on one real-world usage in this post: extracting an array of the keys contained within a JavaScript object.

Click here to read the rest of this post »

If you’ve been working with JavaScript very long, you probably know that you should format curly braces in JavaScript code a certain way. In fact, if you’ve watched my TekPub series, Mastering jQuery, you’ve heard me stop James and remind him that at the beginning of nearly every episode.

However, you’re less likely to have seen a clear example of why this matters or why you should care. Even when you hear advice from a trusted source, it can be difficult to heed that advice if it seems like hearsay or convention for the sake of convention.

While I was working on my recent post about extracting data objects from HTML structures, it occurred to me that some of its example code presented a great learning opportunity regarding this topic. So, I want to take advantage of that opportunity to show you a concrete example of how placing your braces on the wrong line can break your JavaScript code.

Click here to read the rest of this post »

I was talking JavaScript with Scott Hanselman recently, discussing different approaches to client-side development and the complications that surround them. Part way through, he decided that we, along with Elijah Manor, should sit down and make a podcast out of it.

So, we did.

It was just a touch nerve wracking to sit down and record with no agenda, firm topic, or preparation, but Scott’s a pro and guided us smoothly through. Within an hour of him saying “let’s record a podcast,” he had pulled recording equipment and a quiet room out of thin air, and we were finished.

If you’re a regular reader here, the discussion may be below your level of expertise, but it potentially good for sharing with colleagues who aren’t yet at your level on the client-side.

You can listen to it here: <JavaScript and jQuery: Moving beyond Alert() />

Also be sure to check out Elijah’s summary of what we talked about, which includes links to most of the resources we discussed: Hanselminutes #256: JavaScript & jQuery: Moving beyond Alert()

A question that I’ve been seeing more frequently these days is how to extract a JavaScript object from an HTML list or table, given no data or information other than the markup. It’s not ideal to work backwards from HTML, but sometimes you just don’t have a lot of choice in the matter.

Whether you’re enhancing legacy elements that have been generated on the server-side or want to parse the output of a third-party DHTML widget, there are a variety of situations where converting HTML to raw data is a legitimate need. You may have seen iterative solutions to this problem before. However, nested looping code gets messy fast, doesn’t feel much like idiomatic jQuery, and certainly isn’t as concise as you’d probably like.

Luckily, one of JavaScript’s lesser-known utility methods and jQuery’s implementation of it can improve the situation quite a bit. In this post, I’m going to show you how to use this method, jQuery’s cross-browser solution, and how to use it to extract data objects from arbitrary HTML lists and tables.

Click here to read the rest of this post »

I’ve noticed several people looking for a jQuery 1.5 VSDoc this week. After looking around myself, I didn’t see one anywhere either. So, I updated Damian Edwards’ VsDocBuilder for jQuery 1.5 and generated a new VSDoc.

It doesn’t handle the new jqXHR and Deferred return types quite right, so you won’t get Intellisense for the new chained $.ajax() callbacks. However, it should be better than nothing until a fully functioning version is released.

You can download it here: jQuery-1.5.0-vsdoc.js

Update: Damian has just made a fully functional version of the 1.5 VSDoc available (that was quick): jquery-1.5-vsdoc.js. You should use his instead of mine.

Important: This new VSDoc makes use of <para> tags to display line breaks inside documentation tooltips. To view them properly, you’ll need to be sure that you have the JScript Editor Extensions installed so that Visual Studio understands those new VSDoc tags.

In my last post about jQuery Templates, I showed you how to use template composition to build a template out of simple sub-templates. These composite templates are a great way to address the complexity that creeps into real-world UIs, as they inevitably grow and become more intricate. However, one feature missing from my last example was the ability to store those composite templates in external files and load them asynchronously for rendering.

I’ve described how to accomplish that with single templates in the past, using jQuery’s AJAX utilities and a particular usage of tmpl(). Unfortunately, remotely loading a group of composite templates from a single file is not quite as simple, and the technique I’ve described previously will not work.

Not to worry though, it’s still relatively easy.

In this post, I’ll show you how to move a group of composite templates to an external file, how to load and render them with jQuery Templates, and how to take advantage of an expected benefit to improve separation of concerns.

Click here to read the rest of this post »