It’s been two months to the day since my first experiment to see how Jax could be used with Ruby on Rails. Since then, the entire project has been revamped! It is now even more robust, making use of Rails directly and integrating with Rails apps seamlessly. Let’s take a breath, now, and check out an overview of the changes and new additions:
- Lots of TLC for Rails applications. Rails v3.1 and above are officially supported.
- No lack of love for those of you who prefer “vanilla” Jax. If you just need to build a static WebGL application, you can do so with no change in your existing workflow.
- A new development suite has replaced the old interface. It splits the runtime and test suites into two separate sections, since the previous approach of merging them both into the same page invariably ran into performance problems. It also adds a third section, in which developers can test drive their materials in isolation from the rest of the application.
- The runtime section, where the WebGL application is run in its entirety, can be configured to point to any page within the Jax application. This allows you to test drive it such that it behaves exactly as it will in the field.
- All of the guides have been updated to reflect the more minor changes in the framework, and the Getting Started guide has been updated to include how to get started in a Rails application.
- All of the Jax generators now tie directly in with the Rails generator system. They can even be executed with the `rails` command, or executed with the `jax` command for both backward compatibility and as a short-cut so that you don’t need to add the Jax namespace to Rails commands.
As you can see, a lot of work has gone into this release. Expect more posts in the near future that will overview how to make the nuances of Jax work for you.
In the meantime, you should take a look at the Getting Started Guide if you haven’t done so already! It’s been updated to reflect Jax v2.0.
If you’d rather see Jax in action, check out the live demos page.
If you’d like to get involved with Jax development, head on over to the respository at Github!
For those of you using Jax v1.x, there are a few steps you’ll need to take in order to make the upgrade happen:
Follow these instructions if you are developing Jax and are using Ruby on Rails:
- Add Jax to the Rails Gemfile:
gem “jax”, “~> 2.0″
- Install the bundle:
- Run the Jax install generator:
rails generate jax:install
- Scroll down.
Follow these instructions if you are developing Jax and not using Ruby on Rails:
- Install the new Jax gem:
gem install jax -v 2.0
- Generate a brand-new Jax application:
jax new application_name
- Scroll down.
Regardless of whether you are or aren’t using Rails, follow these instructions after generating the new application:
- Copy all app/controllers/ files from the old application into app/assets/jax/controllers/ in the new one. Delete or overwrite the new application controller.
- Copy all app/helpers/ files from the old application into app/assets/jax/helpers/ in the new one. Delete or overwrite the new application helper.
- Copy all app/models/ files from the old application into app/assets/jax/models/ in the new one.
- Copy all app/resources/ files from the old application into app/assets/jax/resources/ in the new one.
- Copy all app/views/ files from the old application into app/assets/jax/views/ in the new one.
- Copy all app/shaders/ files from the old application into app/assets/jax/shaders/ in the new one.
- In the new application, rename all app/assets/jax/shaders/*.ejs files so that their extension is glsl instead of ejs. (Example: common.ejs => common.glsl)
- In the new application, rename all app/assets/jax/resources/*.yml files so that their extension is resource instead of yml. (Example: teapot.yml => teapot.resource)
- Copy all public/ files from the old application into public/ in the new one.
- If you have any plug-ins installed in the old application, install them again in the new one.
If your old code has a lot of //= require‘s in them (controllers were generated with them by default), then the require path is now relative to app/assets/jax. For instance, to require the ApplicationController (which is no longer necessary, but as an example) the path would be “controllers/application_controller” instead of just “application_controller”.
If you have written your own shaders, the setUniforms and setAttributes functions within the material.js file were generated with calls to $super. Remove this call, and also remove $super from the functions’ argument lists.