[caption id="attachment_6264" align="alignnone" width="500"] A clash of the old-school and new-school[/caption]
Over the last couple of years at Shine we’ve built a number of Single Page Apps (SPAs) for large businesses. An app we recently built had to integrate with Oracle Access Manager (OAM), an Identity Management System (IDM) from everybody's favourite enterprise software company. In this post I'm going to talk about a strategy that we used to successfully work around mismatches between the way that SPAs and OAM do things.
Unit-testing Backbone Views is hard. You need to cover enough for the test to be meaningful (for example DOM updates and server calls), without getting too tangled up in gory details. In this post I'll talk about how we use QUnit and Sinon.JS to unit-test our Backbone views.
There's already material out there on using these frameworks together, so I'm not going to get into setting things up. However, having done it for a year now I feel I've learnt enough additional tips, tricks and traps to warrant sharing them with the world.
This post will cover the three things you have to think about when testing Backbone Views, then talk about three strategies for simplifying your tests. I'll also share some more general thoughts on Backbone's suitableness for building large apps.
A leading online learning provider recently engaged us to add social features to their website so that students could more easily collaborate, and thus be more successful with their study. One of the main social features required was providing students with the ability to form 'buddy' relationships, and then to initiate persistent chat sessions between each other. In this blog post, I will describe how we used the Atmosphere Asynchronous WebSocket/Comet framework and the Hazelcast In-Memory Data Grid to build this chat implementation.
In Part 1 of this blog series, we saw how UI state could be maintained efficiently in a Backbone app by introducing view-management infrastructure and retaining references to views. In Part 2, I'm going to talk about how this strategy can be extended to views of collections. I'll also discuss some alternate approaches to the problem of efficient stateful views, and why I chose the approach of retaining references to views. Finally, for bonus points I'll discuss how to manage portions of your UI that transition their state via animations.
One of the good things about single-page apps is that it's possible for them to remember UI state within a page. If an area of the page is hidden from the user, and then redisplayed later, you're able to display that area in the same state that it was left.
This is in contrast to traditional request/response apps, which are mostly stateless, and where maintaining the state of finely-detailed UIs across requests quickly becomes impractical.
However, done carelessly, retaining view state in a single-page app can result in drastic memory leaks over time as the user navigates through the UI.
I'm going to describe a strategy that we've used to efficiently maintain stateful Backbone.js views in a large-scale app. In this post - the first of two parts - I'm going to give an overview of the problem, introduce some memory-management infrastructure, and then propose a solution for simple views. In Part 2, I discuss how to handle collections and animated elements. Note that these posts assume experience with Backbone.
In a prior post, I explained how Backbone.js can be used to implement cascading select boxes. However, this was pretty much just a read-only affair, and these were relatively simple HTML elements. How does Backbone fare creating, updating and deleting data via a much more complex UI component?
I recently had the chance to build a shared calendar tool with Backbone and FullCalendar, a jQuery plugin for a full-sized calendar with drag-and-drop capabilities. I was quickly able to get them playing nicely with each other, and in this entry I'll cover step-by-step what it took to get there.