jQuery UI Widgets, Events, and Cleanup

If you're implementing a custom widget, or extending an existing widget, using the widget factory, care must be taken to cleanup when the widget is destroyed. This includes any event handling. The jQuery UI base widget has an _on() function that's inherited by all widgets to help with not only binding event handlers, but with the removal of them as well. That is, you don't need to explicitly unbind the handlers at destroy time if you're using _on() — something I'm apt to forget about.

View Models and Yet Another Layer

Imagine that we could just transfer the data model our application uses, straight to the client. The client user interface can use this model, the same model the server-side components are using. What's the point? The shared data model, in theory, is a big win because you get at least some level of consistency. The view model is the representation of the application model I'm talking about here - it gets transferred to the client. A replica, as it were, of the reference model. The canonical model that any application components, client or server, should reference.

Tornado and Blob Chunking

The Tornado web framework is a great choice for implementing an application that can anticipate lots of client connections. It's claim to fame is that it can support thousands of concurrent users. And it does all of this in a single-threaded IO loop. Which can block on certain IO operations — like serving large blob objects.

The trick with Tornado is to understand where this blocking behavior occurs, and how that contrasts to the threaded-approach of handling many client connections concurrently. With a threaded-approach, the concept of a request handler, the code the application developer writes to fulfill user requests, doesn't need to do anything special. The framework takes care of maintaining thread management for any given request. With IO loops, we need to be conscientious of the fact that only one request handler is handled at any given time. So the trick is this — exit from the request handler as quickly as possible.

Critical Input Error

Is there such thing as degree of incorrectness when it comes to user-supplied data? As in, you forgot your email address...we kinda need that. Is that a critical error? Is it an every day occurrence that we can expect as user interface developers? Perhaps, we need to design into the experience, and into the data ultimately consumed by the software, the fact that we'll get it wrong. Often. But how do you deal with the paradox of missing data? You can only provide so many friendly messages and so much hand-holding before your software languishes due to data starvation.