Wednesday, September 18, 2013

In a previous post, I described how to fetch a collection using Backbone.js RESTful Persistence. But, this morning, I was a little befuddled as to how to fetch a single object without fetching the entire collection.

The trick is to create a new model with the id attribute and add an options object to the model constructor with the urlRoot property.

But, of course, this required an improvement to PHP code in the "Backbone.js REST with PHP" post. Until now, a GET request always returned the entire collection from backbone.php but I had to update it to check the request URI and, if an object was specified, to find and print that object only.

I've made over a dozen changes to the "Backbone.js REST with PHP" post since I originally published it; I just keep stumbling across new features and quirks which seem to only be covered in bits and pieces all over the Internet.

Wednesday, September 11, 2013

The Internet provides plenty of Backbone.js Router examples but not a simple, straightforward sample that can easily be demonstrated without a web server.

A good example needs to be complete, show a generic implementation that will be often used verbatim and can be easily extended and that will highlight concerns. The following example shows how to implement a Backbone.js Router to access different pages while using a single HTML page and highlights when the page variables will be reset.

Here's some code that you can copy-and-paste into a file named router.html:

Assuming that you have the Backbone.js infrastructure (i.e. jquery-1.10.1.js, underscore.js and backbone.js), you can load this into any popular browser without a web server. For example, if you are using Windows and place your files in the C:\ folder, you can type the following directly into the location bar:

file:///C:/router.html

If you want to visit one of the routes, you can press the "About", "Page 1", "Page 2" or "Page 3" buttons on the web page. Or, you can directly visit the routes by copy-and-pasting the following URLs into the location bar:

file:///C:/router.html#about

file:///C:/router.html#page/1

file:///C:/router.html#page/2

file:///C:/router.html#page/3

Notice how the global variable, visited, is maintained (usually) or reset (when the page is reloaded). It is critical that your design take into account the circumstances under which page variables are reset.

Some other examples neglect to include a call to Backbone.history.start() and, without it, the page does nothing. A confusing oversight!

Hopefully, this example lets you learn about Backbone.js Routers in a straightforward way without pausing to manipulate a web server.

This page creates the initial collection, then executes a series of modifications, then shows the final collection. The modifications are as follows: (1) Bob's age is changed from 20 to 40; (2) Bill's age is changed from 25 to 45; (3) Bill's name is patched to "Billy" and his age is patched to 55; (4) Tim is created and added; and (5) John is deleted from the collection.

It then creates a Backbone.js collection called PersonCollection which, like a model, is a "kind" of object, not an object instance. By default, the url property assigns backbone.php as the server URL that will handle Backbone.js RESTful Persistence.

Then, a collection instance with model instances is created and stored in the people variable.

So far, no REST calls have been made. Backbone.js REST calls are asynchronous so, to avoid race conditions, it is helpful to use a feature like the jQuery promise APIs. The promise APIs allow the developer to make REST calls (or other function calls) to only let the next REST call start only after the previous REST call has finished. The three Person objects in the collection are stored as promises so they can be saved to the backend in order.

A final promise is added to execute the remaining operations. The people variable is replaced with an empty collection and the previously saved models will be load into the collection using Backbone.js fetch() API as a test. A new promise variable is created and promises are made to change Bob's and Bill's ages. Finally, Tim is created, John is destroyed/deleted and the models left in both the client-side (i.e. the collection variable) and the server-side (i.e. store.txt) are the same.

The resolve() function on the promise variable kicks off the actual execution of the promises.

Although I had hoped to avoid the complication of using the jQuery promise APIs in this example, the asynchronous nature of REST APIs make it necessary, even in this simple case.

The only backend is a backbone.php page. It usually works but it has to use some hacks and tricks which aren't kosher. It uses a single store.txt file for a data store in the service of clarity but at the expense of reliability; a database would be better. It also might not work on every PHP server. That said ...

When the sync.html is loaded, it uses backbone.php to synchronize the models from the client-side to the server-side via REST. By setting the url parameter on the Backbone.js Collection in sync.html, Backbone.js RESTful Persistence is activated and directed to backbone.php on the server.

The PHP REQUEST_METHOD is used to separate the HTTP actions into GET, PUT, PATCH, POST and DELETE. The people.fetch() call in sync.html corresponds to the GET action in backbone.php. The person.save() call in sync.html corresponds to the PUT or PATCH actions in backbone.php. The collection.create() call in sync.html corresponds to the POST action in backbone.php. The person.destroy() call in sync.html corresponds to the DELETE action in backbone.php.

The implementations of GET, PUT, PATCH, POST and DELETE all manipulate a store.txt file on the server that stores JSON data for the collection. It is complicated in places to avoid reliance on a JSON library in PHP but the end result is the same: adding, changing and deleting objects from a JSON array which is stored in store.txt.

I wish that the PHP flock() function calls were not necessary but they are a solid but not wholly successful way to handle the race conditions that can occur on PHP platforms. Race conditions can occur when several REST calls are executed simultaneously. Backbone.js does not wait from one REST action to finish before executing another one and, to keep sync.html simple, I've ignored this on the client and used PHP flock() to control this on the server. The log.txt file, which is used with PHP flock(), also serves as a log.

So, finally, here's something to get you started with Backbone.js and PHP.