I recently wrote an article about Abstracting Data in JavaScript.  While that post was really just a vague collection of ideas, I have since had some time to formalize the idea a little more.  For the time being, I will be referring to this UI paradigm as the State Model of User Interface Development.  This article discusses the queueing system in the State Model.

I will be releasing a series of articles regarding my development of this theory from the ground up, and I will be compiling it in one place on The Kevin Dolan.  After I have formalized the theory into some coherent framework, I will publish it on its own domain somewhere, so that it can be made most publicly available.

The current project page can be found here.

With past projects, each request usually consists of a call to some server-side script, along with parameters, and a callback function.  Whenever a call is being made, and another is requested, it waits in the queue until the request is done.  With this technique, a new request needs to be made for every single action.  There is also no polling to get real-time data updates.  The only time a connection is made to the server is when a request is made.

Enter State Model Queueing.  State model queueing has the ability to queue requests in a reasonable way, chaining multiple requests if more than one exists in the queue.  There is also an idea of priority, which can be a clever efficiency boost, reducing the total number of unnecesary calls being made.

To see my example implementation of this mechanism, refer to queue.js v0.1.  Please note that this script is virtually untested, and has several gaps due to the fact that I have not formalized all other parts of this model just yet.

The flowchart below summarizes the State Model queue system:

The best way to understand how this works, is to consider the three possible entrance points, and examine what can happen from each.

Let us begin with some of the terminology I will use.  I have adopted some words I’ve seen flaoting around in my CS days, though I may not be using them correctly.  I apologize if that is the case, but this is what I mean when I use these terms.

A server request is a call made to the server-side file that mediates all data transfer.

An action request is sent to the queue for an action or navigation to occur.

A nonImmediate action request is an action request that does not immediately need a response, and can wait until the next call to the server.  An example of this might be classifying something into a group.  It is easy enough to update the UI dataManager without receiving a response from the server for something like this.  The call to the server simply notifies that this has occurred.

A priority action request is an action that does immediately need a response.  An example of this would be a request for some content, which the user expects to see quickly.

Data polling refers to the act of periodically sending requests to the server, even when no server requests are being made, to check for any possible data updates.

The dataManager object refers to the object which maintains the state of the UI’s data at all times, as discussed informally in the last article.

Initialization

The queue must first be initialized.  Technically, it is possible to instantiate multiple queues, but keep in mind that internet explorer only allows 2 simultaneous instances of xmlHTTP.

The queue is initialized, in the example script, with 3 parameters, call, dataManager, and pollTimeout.

The call parameter is a string representing the URL of the server-side file to manage all communications. We will discuss this portion of the code in a bit more detail, later.

The dataManager parameter is a reference to the dataManager object that will be updated by calls made through this queue.  The actual implementation of the dataManager is the most currently undeveloped portion of this project, so most parts of code in queue.js that would reference the dataManager have not yet been written.

The pollTimeout is an optional parameter, representing the time between idle calls when polling the server for data.  If pollTimeout is not set, or is false, there will be no polling.  Only when a priority request (more on this later) is sent will a server request be made.

When we initialize the queue, we set all the appropriate state variables, and then if the pollTimeout is set, a timeout is set for a call to another function, the poll function.  The poll function checks if the xmlHTTP object is busy, and if it is not, sends a request to the server whether or not there is anything in the queue.

Adding Requests

Making action requests to the queue is accomplished by the public queue.addRequest(..) method, which takes three arguments, request, params and optionally nonImmediate.

The request parameter is a reference to an action or navigation object, as discuess briefly in the last article.  This object maintains what type of action is being performed.

The params is basically any object that can be encoded in a JSON string that represents the specifics of the action being performed.  It could even be null.

If nonImmediate is true, the request will be added to the queue and wait for the next call to the server.  If it is false, or undefined, it will send the request, along with the rest of the queue, as soon as the xmlHTTP object is no longer busy.

When an aciton request is received, the queue automatically adds it to the end of the queue.  If the action request is a priority request and the xmlHTTP object is not busy, the server request will be sent.

The Server Request

So far, I’ve vaguely mentioned what occurs in the server request.  It’s rather simple, actually.

When the server request is made, the queue may have none, one, or several requests lined up.  A call is made to the server-side call file with a single post parameter, param.  This post parameter contains a JSON encoded string representing the time of the last update, and an array of all requests in the queue.

It is then the responsibility of the server-side file to manage and process all requests.  Requests do not expect to receive any input directly.  Rather, the server-side file simply writes a JSON encoded string representing all data that was requested.  It also has the ability to notify actions of failures of any kind, so that they can be handled appropriately.  Errors can include actual errors in processing, but should also be used to validate any parameters sent to the server.

Processing the Response

The response from the server request is a JSON encoded string representing an array of several objects.  The objects are either error notifications, which specify a request identifier and error-specific information, or data-update commands, which ask data in the dataManager to be updated.  As data in the dataManager is updated, UI elements automatically begin responding to the data changes, according to their dependencies.

Data fields are updated first, and the queue keeps track of which requests had errors, and which ones did not.  Currently, the queue can only handle a single error for each call, but it seems reasonable to expect that more than one error could be thrown.  So this should be updated in version 0.2.

After all data updates have been made, the action request objects are notified, in the order they were sent, either that they were performed successfully, in which case any necessary updates can be made, or that something went wrong, in which case, they should be able to respond.

Once the response has been processed, the queue then checks if there are any priority action requests waiting in the queue.  If there are, a new server request is sent.  Otherwise, a call to the poll timeout function mentioned in the first section is made.

That’s basically the jist of State Model Queueing… thoughts?

---

related post