Wednesday, March 21, 2012

fetching ember.js Handlebars templates with jsonp from Scala on Play!

As a setup I should mention that our ember.js javascript application is hosted on a third party page. Since we're using ember.js, the best templating solution is to use Handlebars. The trivial use case of handlebars is to embed the templates in the page itself via a script tag of type="text/x-handlebars". In our case, we're hosted so we can't really control the host page and even if we could, we shouldn't litter it with our templates. Moreover, there are many templates we would use in edge usecases, fetching them all on load will not be a good idea.
The solution we came up with is to fetch the templates on demand or pre-fetch if we see the need coming. Its best to keep the templates as stand alone files, its easier to revision and A/B test with variation of them. On top of that, we must handle the cross domain issue. In our case we decided to go with jsonp instead of CORS. On the javascript side: Note that in the response, the function gets the template html as a string and pass it onto the Ember.Handlebars.compile function to compile it to a handlebars template. Ember.js makes the template globally accessible from code or as an embedded view via the Ember.TEMPLATES map. When creating an ember.js view one should simple point to the template id as in:
On the server side we use Play Framework 2.0. Over there we have a rout in the routes file as in: It basically passes the name of the template from the path and name of the jquery's jsonp callback from the url args.
On the scala side things look pretty simple. Naturally you would like to check for security properties, string injections and A/B testing groups. [plug] QWallet is hiring!

Thursday, February 16, 2012

Testing javascript with Play Framework 2.0 and JsTestDriver

At qwallet we're building an extensive javascript application backed up by a Scala on Play 2.0 backend. Since I'm using IntelliJ IDEA for the scala development, I'm using it for javascript as well. The nice bonus that comes with that is IntelliJ's integration with JsTestDriver.
While working on the javascript app I have it constantly tested on three captured browsers:

The test console shows the test results (super fast) and any console output that got fetched from the browser, e.g:
In the above test example you can see all tests are passing on firefox and chrome, but fail on safari. The sample has three test cases, the expanded one has two test methods. If there's an error, the stack trace is clickable and intellij will take you right to the line of the error. The tests are pretty fast, 6ms on chrome for this small subset means there's some room to grow.
The extra sweetness of Play2.0 is the auto compilation of javascript files. In dev mode the JsTestDriver is serving the library files and test cases to the browser and the application files are served through the Play2.0 application. Play will recompile the files as it detects change. It gives an extra coverage as in many cases the compiler catches things that I may have missed when writing the test.

On CI mode there is no need to pipe the javascript files through play as the files are compiled once. Not that its much faster this way, but it reduces the need of having play running in the background. As we're going to have qwallet operating in Continuous Deployment mode, testing all parts of the application is crucial. JsTestDriver bundled with the closure compiler provides a nice component in the testing strategy with its fast dev mode unit testing.

BTW, we're hiring. If you're interested, shoot us an email to jobs@qwallet.

Creative Commons License This work by Eishay Smith is licensed under a Creative Commons Attribution 3.0 Unported License.