asset pipeline and some fancy generators. But when you break it down, there are better ways to get Spine's source files and who the hell
uses generators? I mean, the only useful one is the initial
rails g spine:new generator. Past the initial project setup, the
spine-rails gem really does nothing but lock you down to an explicit version of Spine tied to that gem release.
I highly advise that new-comers to Spine start off with the spine-rails gem and its new project generator. Then quickly switch to just including the spine source using a git submodule. This will give you the benefit of using the source CoffeeScript files and tracking Spine's git repo which is getting good active development. So let's live on the edge and read some source. First uninstall the spine-rails gem if you have it and add the Spine project as a git submodule to your git repo.
This adds the Spine project to your
asset pipeline using Sprockets. So if you had used the spine-rails generator above and had your spine requires in
#= require spine #= require spine/manager #= require spine/ajax #= require spine/route
To something like the following. Since the
spine/src directory is where the source CoffeeScript files from our submodule
above and Sprockets will render these just fine, it all just works!
#= require spine/src/spine #= require spine/src/manager #= require spine/src/ajax #= require spine/src/route
So now you can easily update your Spine dependency using a simple git workflow with the added benefit that you can open up any of the source CoffeeScript files and learn Spine from the inside out. You can even change the source or put in console debugging to see what is happening and your application files will recompile via Sprockets on the next request.
- Rails & Spine.JS - Using The CoffeeScript Source
- Rails & Spine.JS - Jasmine Testing Part 1
- Rails & Spine.JS - Jasmine Testing Part 2
- Pretty Console Logging With Guard::Jasmine & BlackCoffee