Integrating Single-Page Apps with Oracle Access Manager

berlin_-_old_and_new
A clash of the old-school and new-school

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.

Testing Backbone Views with QUnit and Sinon

Clock parts

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.

Web Directions Code 2013

logoThe second incarnation of the Web Directions Code conference was this year on 2.-3. May, and I was fortunate enough to both attend and speak. The conference held in Melbourne Town Hall was the place to geek out about all things web: JavaScript, HTML5, and CSS3.  More than 250 web professional turned up to learn about new directions the web is taking. In this blog I will summarise those talks that left the biggest impression on me.

Backbone Boilerplate Vs. Rails Asset Pipeline

We recently shifted from Backbone Boilerplate to the Rails Asset Pipeline for generating the various assets (Javascript, CSS, HTML, images, etc) that comprise teamstuff.com, a single-page app. In this post I’ll talk about our motivations for making the shift, what we had to change to get there, and how the end result turned out.

A Chatty Atmosphere

6048635_s

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.

Efficient Stateful Views With Backbone, Part 2: Collections & Animations

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.

Efficient Stateful Views with Backbone.js, Part 1

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.

Building a shared calendar with Backbone.js and FullCalendar: A step-by-step tutorial

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.

Cascading Select Boxes with Backbone.js: A Step-by-Step Tutorial

What happens when you don’t use Backbone

Up until recent years, client-side Javascript development has resembled the wild-west from a software design perspective. Libraries like jQuery have certainly helped, but with the rise of Single-Page Applications, jQuery alone doesn’t provide enough of an overall framework for large-scale client-side development. Fortunately, there’s been a recent proliferation of Javascript MVC frameworks, both large and small. Backbone.js is one of these. It’s lightweight, works with jQuery (although it doesn’t need it) and seems to have some momentum behind it at the moment.

Backbone.js isn’t particularly large or opinionated in the manner of say, Rails. For an expert, that might be a good thing. But for a beginner, it’s not so good. The API documentation is complete, yet joining the dots can be a little intimidating at times to a newby. Simple tutorials abound that describe how to hook up a single view to a single model, but it’s unclear what approach to use for more complex UIs. What should be in a model and what should be in a view? How should models and views interact with each other?

I have recently had the opportunity to work on a non-trivial Backbone.js application. In this entry I’ll try to present an example that is slightly bigger than your average single model and view. Furthermore, I’ll present it in a manner that is iterative, rather than just dropping the whole thing on you in one hit. You’ll see that Backbone.js provides a good basis for building apps in an MVC style, although you will be faced with the same design decisions you’d have to make with any other MVC framework.

Note that this isn’t an introduction to Backbone.js, and assumes a little background knowledge of how the framework works.