Recently at work we’ve been in heavy development mode on a new thick-client application architecture.  If you aren’t familiar with the concept, thick-client essentially means putting most of the work onto the client’s processor, and removing it from the server.  The benefits of this are many, not the least of which is a much faster site response time for your users, and a much lighter load for your server.

To accomplish this basically means using javascript and a lot of AJAX, as well as implementing the application such that that a) search engines can still index your site and b) the user can both bookmark and use the back button wherever they are in your app.

In order to facilitate this heavy use of ajax and management of state, a number of MVC(ish) patterned javascript libraries have been created, and more appear seemingly every week.  After a little bit of research, we settled on Backbone due to its barebones nature, low overhead, lesser learning curve, and the size of the community.  It always helps to be able to reach out when you get stuck.

In combination with jQuery (we are already using it heavily), and Require.js (a dynamic resource loader which has also been in use for quite a while), we had the perfect trinity of tools to get the job done.

Basic App Structure

There are a lot of things to consider when architecting a large application.  For HMS, this is compounded by the fact that a) we have a lot of users with a lot of different site configurations, b) we have different variations on the main backend application, c) there is a lot of legacy code and newer front-end logic that needs to maintain compatibility so that pieces can be added one at a time.   This is where Require and its support of AMD (asynchronous module definition) really shines.

All of our thick-client application code is managed through AMD, and there are two things about it that are very awesome:

1. It allows seamless integration on a module-by-module basis with the current application code
2. Even portions of modules can be broken out and used before their parent module is complete – for example, we already have the autocomplete module live, even though the search module is still in development. When the time comes, it will be trivial to move it back into its proper place.

The general application structure goes like this:

1. Event Aggregator
   Outlined here, we have a single global object, and its job is to manage communication between modules.
2. Outer Router
   We have two routers.  This helps keep the application router a lot simpler, and keeps module related logic inside the module. The outer router manages routes for the entire application, and determines which modules to load.
3. User Module
   Right now, this is the only module that sits everywhere in the application. As such, it is loaded by the outer router.
4. Modules
   Each module contains its own router as well as templates and views. The router loads the views, the views load the templates (we’re using Hogan).  When we compile with require, each module (including templates) becomes a single file (the module router).
5. Models
   The models are the glue between the client and the server,  and they sit in their own folder because multiple modules may use the same models.
6. Form Mediator
   This is actually one of the modules, but its worth describing here.  We use a special Backbone view to handle every form, enhancing functionality as we go.  This view simplifies forms immensely, managing the model, validation, and state with ease.  Its special power is to allow multiple modules to combine into a single form definition – most usefully for search / advanced search.
7. UI Modules
   Most DOM manipulation (outside of insertions/removals)  and all UI effects are offloaded into separate UI modules.  The reasons for this are a) it separates presentation concerns and b) it allows for a much easier time should we decide to switch from jQuery for future manipulation (one can dream of full standards support across browsers)
8. Backbone.Store (localStorage)
   Of course we’re using this for our app.  Currently it persists forms, helps maintain the user session client-side, and caches model data.

Obviously, there are many ways to architect a thick-client application.  Our approach intends to prevent module dependency (outside of UI Modules), separate DOM manipulation from data logic, keep communication centralized in an event aggregator, load quickly (through smart module loading and use of localStorage, among other things), and preserve the global namespace through the use of AMD.  There are a lot of details I’ve left out (for instance reuse for mobile), but I do hope to dive a little deeper in future posts.

There was already a great library for Backbone to utilize HTML5 localStorage functionality; however, there were a few drawbacks to the library that caused me to look in another direction, and ultimately led me to creating Backbone.store.

My two greatest needs were:

1. The ability to utilize the storage mechanism as a cache.
2. A greater range of compatibility outside of localStorage support.

To meet these needs, I turned to Lawnchair, a JSON storage library with a wide range of adapters for different storage types, mixed in a little bit of the aforementioned backbone.localstorage plugin, and came out with the beginnings of a (hopefully) useful storage middleware.

While the overall project is in very early stages, its not too soon to look at, play with, and provide feedback on.

Download / clone from Github.

Features:

1. Can be used with or without a backend server
2. Configurable cache time to live
3. Configure when to use server vs cached model – great for list  vs. detail of a record
4. Does not require localStorage support, though a Lawnchair adapter may be needed to get the support you want.

Planned enhancements:

1. Batch model upload to server (online/offline or time delayed)
2. Parameter based caching (for caching paging / search results / etc)
3. Remove Require (AMD) dependency
4. ??? (accepting ideas)

Also included in the project is a basic ‘Todo’ style application including a CodeIgniter (php) based RESTful web server and structure, and a Backbone/Require/jQuery front-end consisting of a list/detail view with complete CRUD control and proper routing using both direct (bookmarkable) URL access and pushState routing.

Again, this project is nowhere near complete, so I’m sure there are some bugs… Still on the todo list is to add test cases using Sinon and Jasmine, and there is a known issue with the list -> detail -> list navigation.

DynoMenu was conceived to solve a problem on HomesConnect.  Since HomesConnect is a CMS that allows users to add new pages and new menu items to their navigation, and since the navigation is horizontal across the top of the page, the need arose to be able to maintain the layout of the templates while removing the burden of keep the navigation usable from the agent.

The solution was this plugin, which will first try to shrink the navigation font to a determined size, and if failing will systematically remove navigation items until it achieves the best fit. These items are placed in a ‘more’ link which becomes the last main navigation item, and can be accessed from there.  Since the agent can determine the order of their navigation via a drag and drop interface on the backend, it is easy for them to decide which items will fall under the ‘more’ link by pushing them to the end of the navigation.

In any case this may not have much use outside of CMS systems where you cannot control the total number of nav items, but who knows.. maybe there is a use case I’m not considering.

Download it from Github here.
See a demo.

Luckily, there is a fairly easy workaround for this situation as long as you are not trying to do too much with the pngs. It will even fix pngs in IE6 for you too (in fact, that is the real purpose of the script). That workaround is the jQuery ifixpng2 plugin, written by Yereth and available here.

All you need to do is install the plugin and use it on the PNG containing objects (images or backgrounds) that you would like to fade. There are two changes you will need to make however:

Line 64 looks like this:

ltie7	: $.browser.msie && $.browser.version < 7

You’ll want to change the 7 to a 9 (in hopes that this is fixed for good by IE 9, otherwise you’ll need to go back and change it to 10 later).

The other change you need to make is on Line 149, which looks like this:

for (prop in expr) elem.style.setExpression(prop, expr[prop], 'JavaScript');

Internet Explorer 8 doesn’t support setExpression, so it will throw an error, unless you add an if statement to keep it from running:

if( $.browser.msie && $.browser.version < 8 ) {
for (prop in expr) elem.style.setExpression(prop, expr[prop], 'JavaScript');
}

That’s all there is to it. Happy fading!

In the old days (2 years ago), working the Javascript magic to create a cool AJAX based event took a fairly decent working knowledge of the mechanisms behind the process.

With the increasing popularity of Javascript libraries however, this type of functionality became available to the web site hobbyist, and was made much easier for the web site professional.

The following step-by-step tutorial will show you how to combine the power of JQuery (a javascript library that weighs in at about 20k) with Code Igniter (a PHP framework based on the MVC design pattern) to quickly and painlessly pass a record ID through the javascript and over to the server, where it will be passed to a mysql database, used to retrieve some data, and sent back to the page for display.

Step 1
We begin by assuming that you have a div with an id of content, which is where you would like your freshly retrieved data to display, once it has been freshly retrieved. For this exercise, you have already taken an action to call your javascript function with a record ID parameter.

The first thing you need to do, is make sure JQuery is being loaded, and to create a function for your AJAX request.

Step 2:
Next, youll use the JQuery function load, and attach it to your content div:

function get_record_id(record_id) {
     $('#content').load()
}

Step 3:
The load function accepts three arguments. The page to be called on the other side of the HTTPRequest, the array to pass through the POST, and a callback function. It looks like this:

function get_record_id(record_id) {
     $('#content').load(/controller/method,p,function(str){

	 });
}

Lets go back to that. Code Igniter URLs are created by calling the name of your controller, followed by the function inside the controller class that will handle your request. If your server does not support mod-rewrite, you may also need to append an index.php to the beginning. The str inside the callback function is the results of your AJAX request. There isnt much use for the str when using the .load function, but it does come in handy using the other JQuery AJAX functions – $.post and $.get, which I assume are self explanatory.

Step 4

var p = {}; //instantiate the array
p[record_id] = record_id //assign your record_id variable to it.

Thats all there is to it. Your final javascript function looks like this:

function get_record_id(record_id) {
     var p = {};
     p[record_id] = record_id
     $('#content').load(/controller/method,p,function(str){

     });
}

Step 5
On the CI side, you have a controller and method setup something like this:

class Controller
{
   function Controller()
   {
       parent::CI;
   }

   function method()
   {
   }
}

The important part is the method() function, as it will contain some of the code we need to make things happen.

Step 6
The first thing you need to do on the CI side is retrieve the value passed through the request object. This is simple enough, using $_POST[record_id]. You also want to load up your database model so you can get the record out of your database. So, well load the database library, and then load the actual model. Then, we want to send the record ID to the database, get the resulting data, and pass it back out to the request. our function starts to look like its doing something useful pretty quickly.

function method()
{
   $record_id = $_POST[record_id];
   //set the record ID
   $this->load->library(database);
   //load the database library to connect to your database
   $this->load->model(records);
   //inside your system/application/models folder, create a model based on the procedure
   //outlined in the CI documentation
   $results = $this->records->get_record($record_id);
   //get the record from the database
}

Step 7
At this point, we need to go into our records.php file in the model folder. Since Code Igniter uses a Model-View-Controller structure, database activity, server-side processing, and client-side display should be as separate from one another as possible. You dont NEED to do this for Code Igniter to do its thing, but its good practice.

Inside the records.php file, well create a method called get_record to match the method referenced above. Well use it to get a record by its primary key of ID, put the resulting data into an array, and send it back to the controller, out to the view, and ultimately into the content div we started with.

function get_record($record_id)
{
   $this->db->where(ID,$record_id);
   //we want the row whose ID matches the value were passing in
   $query = $this->db->get(record_table);
   //get the table and put it into an object named $query
   $row = $query->row();
   //gets the first row of the resulting dataset.  In this case, only 1 row will ever be returned
   $results[record][$row->ID][name] = $row->name;
   //here, we create a multi-dimensional array holding the returned values
   //based on the key.
   return $results;
   //send the record back to the controller
}

The trickiest part of this section is the array. It seems pretty complex from here, but youll see soon enough how it breaks down into something more manageable as we go along.

Step 8
Were back to the controller again, and we have one more line to add – this time to pass the resulting data into a view to be formatted and printed to the content div. The whole method() function now looks like this:

function method()
{
   $ID = $_POST[record_id];  //set the record ID
   $this->load->library(database);
   //load the database library to connect to your database
   $this->load->model(records);
   //inside your system/application/models folder, create a model based on
   //the procedure outlined in the CI documentation
   $results = $this->records->get_record($record_id);
   //get the record from the database
   $this->load->view(AJAX_record,$results);
}

Step 9
The AJAX_record.php file should be in your system/application/views folder. Keep in mind, that when you pass an array to a view (in this case the $results array), it will be exploded inside the view. So, the path to your record is now $record, instead of $results[record]. Also inside will be your standard HTML markup, and something like this:

< ?php foreach($record as $id=>$value) { ?>
     The name associated with this record is: < ?php print $value[name];?>
< ?php } ?>

This output is what php is sending to the request object, and is also what gets loaded into the content div. Code Igniter and JQuery make it that easy to dynamically load data using AJAX.