Hacking Away a Web-Based Staff Client

One of the focuses for the recent Evergreen Hackaway was the web-based Evergreen staff client.  (see discussion notes  I spent a lot of my time there building small prototypes and discussing various web development techniques and practices with the other developers.  One development framework/toolkit that came up in multiple conversations (though probably initially from Dan Scott?) was AngularJS (, so I decided to check it out.

What started as a due diligence experiment quickly turned into a wee bit of obsession.  For those of you with an interest in web development, particularly the logic end of things (collecting data and getting it into the DOM), I recommend taking a look at the Angular site.  They’ve built a very compelling framework that’s a lot of fun to use.

I decided to build something more than we set out to build at the Hackaway, which was originally going to be a simple checkout interface.  I wanted to test Angular by creating something sufficiently complex that I felt comfortable recommending it for the staff client.  A lot of frameworks work fine for small applications, but they break down with larger, more complicated applications.  I’m happy to report I have not run into any brick walls, just the opposite, in fact.

Before I go too far on what I like about Angular and what I experimented with, here’s the code I put together:;a=shortlog;h=refs/heads/collab/berick/web-staff-ui-angular

I’ve also installed the code on one of Equinox’s demo servers.  Test login is admin/demo123.


  1. The only features that work are patron search and checkout, and those are very basic.
  2. My primary focus was the back-end framework, not the UI.
  3. Tested in Chrome and FF.  (FF requires a recent version of OpenSRF).

The core of Angular is their model/view/controller mechanism which very effectively separates data from presentation and removes the need to perform direct DOM manipulation, which is cumbersome and brittle.  The Angular home page is full of great examples of this, so I won’t go into too much detail here:   Suffice to say the HTML templates are easier to read, there is one less step of indirection between the templates and the code, and the code need not know anything about the internal structure of the markup.  It makes no difference to the code whether the data collected is destined for div, table, li, etc.

Another great feature, which is not unique to Angular, but which they have done a great job implementing is the HTML5 pushstate routing.  This is a mechanism by which the browser URL may be modified by script, without actually reloading the full web page.  With this, we can create pages, which act as stand alone, deep-link-able web pages, but can also be loaded much faster when working within the confines of the application.  This is especially important when each page load means fetching some amount of data.

For example, these two URLs point to individual web pages, but when navigating between them via the “Checkout” and “Items Out” tabs, the pages are not reloaded, instead they are simply redrawn with a new context.

There are a lot of other nice features, too, like tight integration of promises/deferred objects, extending HTML via local directives, integrated test framework, and more, most of which are demonstrated in my experimental code.

You may also notice that I’m making heavy use of Twitter/Bootstrap for CSS and UI components.  This makes building prototypes a whole lot easier.  (Get it, bootstrap?? ;).  Depending on your browser window size, pages may flow and break funny.  This is partially on purpose to see how pages respond, but it clearly needs better planning.

What did I take away from this experiment?

  1. I really like AngularJS.  Its focus is narrower and it does not do everything Dojo does.  If we were to consider it as a replacement for Dojo, there will necessarily be other components to leverage and some amount of tool rebuilding. 
  2. While I don’t have any strong opinions about which canned CSS we use, we must use something and it must exist before development begins in earnest.  (Sorry for doubting you, Dan Wells :)

Comments and feedback are appreciated.  Apart from the obvious it’s-a-half-baked-hack, I tried to create something that on the back-end was a reasonable stab at how a web-based staff client might be structured.  I’m also curious about everyone’s take on Bootstrap.  If we used it, we would need our own theme, of course, but in general,.. eh?