Filtering ExtJs Grid

ExtJs Grid provides a nice, quick way to build a UI that can handle a lot of tabular data and support the operations you’d typically like to perform on that data (sorting, filtering). It can be hard to style, but is great for whipping up admin CRUD functionality.

One thing that seems hard to do with it out of the box, however, is trigger filtering directly from your javascript, rather than via the UI.

Ext.grid.Panel does in fact expose the requisite properties and methods to accomplish this, but they’re a bit hard to track down, and not part of the official public API. This gist, GridFilteringExtensions.js, adds some methods to Ext.grid.Panel that make this easier. It probably won’t accomplish everything you want to do, and hasn’t been tested in a wide variety of situations, but it was exactly what I needed, and may be a good base from which to build.

Note that before manually setting a filter for the first time, you’ll need to call `createFilters`.

closure compiler externs for underscore 1.4.4

Closure Compiler externs for underscore 1.4.4 are now available.

Underscore 1.4.4 adds two new functions, _.findWhere, and _.partial.

Also pushed some fixes to 1.4.3 externs:

  • typo in `properties` param for _.where
  • a bunch of methods should be able to operate on Arguments objects as well as Arrays. Previously, only Arrays were noted as valid params by the externs.

Simplify QAing the js popup windows in your web app

QAing js popup windows in your web app is a pain in the ass. It’s easy to miss windows in obscure corners of your UI and can be hard to recreate the circumstances under which they’re shown, and the various states that determine how and when they appear. Automated js tests with a library like Qunit or Jasmine, while great, don’t really help when you need to make sure things look a certain way.

Fortunately, if you make a couple assumptions that I think hold true for a majority of web apps, we can simplify this testing process substantially.

Closure Compiler externs updates

Just pushed fixes and updates to my Closer Compiler externs for underscore, and created a repo for Qunit externs (which is probably not of any use to anyone, but is used by for testing accuracy/completeness of underscore externs).


  • Externs for latest underscore (1.4.3).
  • Some fixes to 1.3.3 externs, indicating that more methods may return wrapped objects (this is still incomplete).
  • Tests for externs file completeness/accuracy by running underscore’s own qunit tests through closure compiler. The output (using advanced compilation) is nasty and contains a lot of errors, but most of them are irrelevant. Some do point to legitimate issues, mostly related to uncommon ways of passing arguments to various methods.


  • Externs missing for `throws`, callbacks, and configuration. Mostly complete.

Closure compiler externs files for underscore and backbone js

As part of some other things I’m working on I’ve begun building upon some existing closure compiler externs files for the Underscore and Backbone js libraries. Both are still in quite early stages, but if you need something like this, they’re currently better than nothing.

backbone-js-externs on github, for Backbone 0.9.2

underscore-js-externs on github, for Underscore 1.3.3

The Backbone externs file is taken from this gist, which was autogenerated by DotNetWise’s externs extractor. It does a decent but very basic job.

The Underscore externs file is taken from the official Closure Compiler repository. The only changes I’ve made so far are

  • fixing a type annotation for the _.uniq and _.unique functions that had a required parameter after a non-required one (Closure Compiler dislikes this)
  • using same type annotation for _.uniq and _.unique, since the latter is an alias for the former
  • beginning to add type annotations for functional-style usage of underscore, vs. object notation (e.g. _(collection).map(function(){}) vs., function() {}). The existing externs file has only the latter.

I’ll probably also be adding externs for use with the SVG library Raphael at some point.

Errors in scripts loaded with jQuery $.getScript

Spent some time the other day trying to figure out why I wasn’t seeing JavaScript errors in certain files where I expected to, which was problematic both for development and also for the monitoring of client-side errors we’re doing in the application (assigning a handler to window.onerror that makes an ajax call with error information to an endpoint for this purpose).

Basically, if there are errors in any of the scripts you are loading with $.getScript, or the full $.ajax call for which $.getScript is shorthand, these will be caught by jQuery and will fail to show up in the console or be passed to any window.onerror handler you’ve defined. jQuery provides a global ajaxHandler you can attach to, for example, document, which you can then use to do whatever client-side error handling/logging you want to do.

The downside of this approach is (as far as I can tell) that you don’t get quite as much error information (specifically, the line number of the error) from jQuery as you do from other ways of loading scripts with js, because the error gets caught during a call to eval (or more specifically, jQuery’s globalEval method).