Front end Javascript

The front end of an Iguana App consists of a few simple components.

As with the back end, the best way to understand the front end is to install at least the Channel Manager and have a poke around the files.  In this page I’m continuing with links into GitHub showing the actual code. I recommend looking at them in a separate window as you read through my notes here.

There is usually just one HTML page.  The one for the Channel Manager looks like this.

You’ll notice a few things:

• There is almost no traditional HTML content. This is key; we generate all the HTML on the fly using Javascript.
• The HTML file itself is like a project or dependency file. it simply lists the Javascript and CSS files we need to load.

This is not your father’s web application (ha ha – my father, rest his soul, could barely use a browser…).- Using traditional template based programming, like people used to do with PHP, is what gave web applications a bad name. That style results in sluggish applications that hog bandwidth.

Instead, in these apps we use window.onhashchange. You’ll notice all the URLs in an Iguana App contain a # character. This character, and everything that follows it, is called the hash. When it changes (usually because a user has clicked a link), modern browsers issue a hashchange event. window.onhashchange allows us to override the default behaviour of the browser and perform our own work instead.

So Iguana Apps are built with a mini Javascript framework that creates virtual pages. When the hash changes, we trap that event, we refresh the screen and, we create a new view.  This is done with a tiny library I wrote called lib.page. It is based on a similar one the Iguana translator uses, but it’s cleaner and simpler (no support for old IE versions and we know how to write better Javascript now). A lot of modern web frameworks use a similar trick.

It’s simple and convenient to use.  Here are a couple of examples:

• In the channel manager.
• And in the bed monitor.

There are a few key points:

1. We use the jQuery ready event to initialize the library and pass in a hash table of functions.  It’s very analogous to the table of JSON web service handlers we have in the back end Lua.
2. To create a new page it’s simply a matter of assigning a new function within that page table.
3. To change one of these pages we simply have to put in a hyperlink of the format <a href=”#Page=<page name>&Parameter1=Data&Parameter2=Data”>.
4. The framework passes the parameters as arguments to each function as it’s called.

It’s a lot of fun. It makes it so easy to add pages quickly just editing a single file. And it’s really snappy since you are not doing full browser page refreshes as you click. This gives you a lot more mental bandwidth to think about what your application needs to do.

Best of all, these pages behave naturally for users – the Back button on the browser works properly with this approach, since there is a proper browser history to follow. The virtual pages may be virtual, but they still map to real URLs.

The code in the page handlers makes heavy use of jQuery to manipulate the HTML. There is also a technique of relying on small helper functions which can be used to build out common page elements such as headers and footers.  See the helpers for the channel manager, for instance.  This approach makes it much easier to maintain these applications, since the helper functions don’t change their behaviour.

To execute actions and get data from the back end Iguana Lua server, the app makes AJAX calls.  Initially we chose to use a convenience helper library called lib.ajax in order to have a default error handler. Although later we realised that jQuery itself allows setting a default error handler so we are deprecating that little helper library.  We have code in the Lua back end which will catch Lua exceptions and allow them to be handled by a standard error handler, which displays meaningful messages to the user in the web GUI.

And that’s about all you need to know to be dangerous around the front end of Iguana Apps. There really isn’t a lot of code to them. That’s a deliberate and careful design, to make them easy to understand, and more importantly, easy to alter and extend.

So I do encourage you: go in and get your hands dirty, hack these around a bit, be creative. Above all, have some fun.

The next few sections talk about a few interesting component libraries in the apps that offer some awesome capabilities.