Friday, April 27, 2012

Backbone.js: cha cha changes - keep your client in sync

In rich client javascript applications it is often desirable to keep your client side representations up-to-date with any changes that happen on the server. This post describes a strategy for doing so when using Backbone.js.

We could have every model take the responsibility for polling the server itself, but that would typically mean an awful lot of unnecessary requests. To reduce the number of requests, we can have the Collection do the polling. Yes, we lose being able to us HTTP's conditional GET, but sometimes we have to eschew high ideals in the real world!

Thanks to this pull request being incorporated into backbonejs, doing this just got a little easier. Now we can provide a merge option to Collection.fetch() which will merge rather than discard duplicates. Note you also have to provide the add option or the reset would naturally be called removing any existing models from the collection. I'm also assuming all models have a lastUpdated attribute. Such an attribute is quite common for domain classes on server side frameworks like Grails and Rails.

Grails Quartz Error

Some day, if you have many quartz jobs in Grails (though it only takes 2), you might stumble upon an error like this:
context.GrailsContextLoader Error executing bootstraps: org.quartz.JobPersistenceException:
The job (GRAILS_JOBS.com.saasplex.app.AppInstanceHourlyJob) referenced by the trigger does not exist.
The reason for this - at least in my case - is that I had copy pasted to create a new Job. The old copy paste syndrome! In doing so, I ended up with two triggers with the same name. Trigger names must be unique across all Jobs.

Monday, April 2, 2012

Grails pro tip: front-end dev and the resources plugin

I love the resources plugin than now comes by default with Grails. So much so I've authored or contributed to a number of related plugins. One frustrating aspect to the resources plugin had been the random hashy filenames I was seeing in development for all my client side files. In order to drill down into a particular javascript file for example, I had to examine the content of each file until I found the right one. Tedious it was, but finally I bit the bullet and went about looking for a solution. I added the following to the development section of my Config file, and now I see all the respective file names:
grails.resources.mappers.hashandcache.excludes = ['**/*.js','**/*.coffee']
Note: there is of course a means of completely disabling the resource processing, but would mean my coffeescript files would not be compiled.