A Better Ajax throbber

I’ve been messing with setting up an ajax throbber ( the little waiting icon or animated gif.  That’s what they call it.  It ain’t me. ).

Most examples show that you should put the show() logic right before you make your ajax call and then the hide() in the $.ajax.complete() event.  This has a number of problems. 

1) Unless you have just one single repository through which all ajax calls go ( and I do ) you end up putting the start throbber logic all over the place, wherever you make a call

2) unless you use a setTimeout function the throbber will always show even if just for a flash.  It’s much better to have a pause and if the ajax call is quick enough then you don’t see the throbber at all.

Number two has a major problem though.  And this is the meat of the post.  If you set your time out for 1000 ( one second ) and the ajax call comes back in 500 then the ajax complete will fire before your setTimeout has fired.  Then the setTImeout will fire and the throbber will never disappear.

Two ways to deal with this are to put the hide() logic in the repository call back method which unless you have a single repository as mentioned above with a single OnComplete callback that then calls your real callback you end up with code everywhere again.

So what I decided to do is to have global ( or scoped to your module global ) variable called showThrobber, and set it to false.  Then in the $.ajaxSetup.before send I put my timeout with a check for showThrobber. in the $.ajaxSetup.complete is set showThorb to false and hide the throbber.  so it looks like this

$.ajaxSetup({
            complete:function(){dci.showThrob = false;  $("#ajaxLoading").hide();},
            beforeSend:function(){setTimeout(function() {if(dci.showThrob) $("#ajaxLoading").show(); }, 500)}

});

In my ajax get ( or post ) I turn on the showThrob

ajaxGet:function(url, data, callback){
             dci.showThrob=true;
           // showLoader = setTimeout(function() {if(dci.showThrob) $("#ajaxLoading").show(); }, 1000);
            $.get(url,data,function(result){repositoryCallback(result,callback);
            });
        }

sorry about the formatting.

This is I believe called a latch mechanism.

How I use Backbone.js Views as modules

In my previous post I explained how I use views as a basic class structure. Here I will go a bit deeper into how I use them.

At the base there is the traditional Backbone.js view.  Used as one would normally use it, to set up the container, hook up the events, and structure your code.  This is a nice way of compartmentalizing functionality.  But let’s say that you have two views, or pieces of functionality, say a popup functionality and an ajax form functionality.  You  could initialize the two views separately and then hook them together using a controller ( more on that later ) but if you do this a lot, and this is the sort of thing one would do a lot if they are using popups, then this get’s terribly tedious. 

So I employ what I call a module.  It’s an extended view that has a views collection ( object ) a modules collection and a destroy function();  Then I inherit this module, and in it I instantiate the ajax form view, the the popup view put the form in the popup and render. I put both views in the modules view collection.  The destroy method loops through the modules and the views that belong to the module and calls destroy and remove on them respectively.  Now I can call new AjaxPopupModule() pass in an el ( a root element ) and a url and possibly other stuff and I’m all set.

Using Backbone.js views as a class structure

So what I’ve ended up doing is using Backbone.js Views basically as a class structure.  I used to use immediate functions or static objects or whatever you want to call them, basically

var x= (function(){

return {

}

}())

for everything.  And I always had an init function to set it up.  The limitation was that I could not inherit from those classes so I eneded up duplicating code a lot.

So, as I was saying, I’ve adopted backbone.js views as my class structure.  I can inherit these classes, they are constructor functions so I can put set up code in the function and they offer a few bonus features as well, such as if I have straight up events I can use the views event declaration infrastructure.  But overall what I like the most about it is that I can create base classes that have the functionality that I use a lot on them.  Now I know I could write my own class structure and implement all these features as well as a couple I’m about to mention that I don’t like, myself, but a) I’m kind of scared of constructer functions with prototypal inheritance and b) I believe ( hope ) that the structure will be familiar to people who use backbone.js ( such as my team ) and they will understand what is going on more easily.

The one thing I don’t like about using backbone.js views as my base class structure, is that it doesn’t implement any override functionality.  You can overwrite but not override and call base().  This would be great for such things as having a function on a base class called registerSubscriptions() that lays out the common subscription.  Then in my inhertied classes I could override it add page specific subscriptions then call base().

The way I get around that now ( and there are I guess a couple of similarly distateful ways ) is that I have my base registerSubscriptions() call registerAdditionalSubscriptions() as it’s last step.  in the base class I stub out the method so it won’t crash and in my sub classes I overwrite the method if necessary.

My javascript stack

Ok so here’s how I’m building my single page business app.

Backend is asp.mvc using fubu html helpers. 

front end.  Here are the plug ins I’m using. jquery ( of course ), backbone.js, a little pub sub class, $.address, knockout.js and my own system of controllers.

A lot of people talk about not using any controller, just straight backbone.js or knockout.js.  I can’t seem to figure this out.  My shit has lots of stuff going on that has no place in a view or a model but I don’t want it just hanging around willy nilly.  I need a freakin controller to manage all the different parts. 

For instance, when you click on a row in the grid, it must hide the grid and show a form.  When the form submitted or canceled it should remove the form and show the grid again.

First I hide the grid so that I don’t have to re load that section.  If the form is updated rather then canceled I update the grid but I don’t have to get the whole def and re render everything.  The form however, I retrieve via ajax.  This is because there could be different forms based on what exactly is clicked on the page/grid and loading a form for every possible outcome is crazy.

Even so that might not seem like it’s that crazy that I just absolutely need a controller, but here’s a real example of the basic page in out app.  We a) load a grid. click on the grid and you get b) ajax call for form. On the form there is the ability to associate a document with this particular instance of the entity.  If you haven’t any you can upload a new one.  But you can’t just upload a document you much attach some meta data to the document so we need a c) new ajax form and a d) new popup to house it.  then you save the doc and meta data and you see it in a list of selected documents for this item.  If you want to edit/view one of these docs you can click on the name and up comes the popup with the form and data.  This is the basic page and shit just gets more complex from there. 

So in my next post I’ll explain my controller and how it keeps me sane.  But it’s friday 6:00 and I still got shit to do so I’m out.

Catch up and more Javascript

well it’s been forever since I’ve posted but don’t worry I haven’t learned a thing.  I will dispense with the backlog and jump straight into what I’m doing now.

Javascript

I am working on a single page app with basic business app functionality eg lists ( grid ( jqgrid )) forms, menus, popups etc.  I of course quickly found my javascript btfu ( getting ugly and out of control ).  So I started writing my own collection of classes to organize and componentize the functionality.  After a few iterations I had something pretty workable but I’m using Douglas Crockford’s objects with private variables.  These are nice and clean and organized but they don’t allow for much extension or inheritance.

I’m still using these but I have integrated backbone.js and am about to integrated knockout.js in there to.  I will write an other post explaining this stuff so people don’t have to read this bullshit if they don’t' want