Rails 3.1

Asset Pipeline & Engines

What's new in Rails 3.1

Asset Pipeline
Engines
HTTP Streaming

Asset Pipeline

Asset Pipeline is a process by which css, javascript and images automatically compiled (from SCSS or coffee script), minified, compressed (gzipped) and fingerprinted for you
Asset Pipeline requires the assets to be placed in a special place.
There are three locations where you can keep all your assets (images, css and javascript)

app/assets - All App related assets
lib/assets - All the assets which can be shared across multiple applications but they are still your assets
vender/assets - These are third party libraries JQuery, Backbone.

Asset Pipeline makes it easy to organize and keep the assets manageable.
We have created a very detail structure which Yaz will talk about it in a bit. We have also removed Velocity templates and instead using manifest file to do those merging. (No imports in SCSS file)

Manifest Files

Asset Pipeline requires manifest file to compress files together, generally speaking we will have manifest per layout (i.e. Summer Reading, Core, Acquisition, readers).
Previously we had used javascript_asset_expansion to combine all those files. However, Asset Pipeline is much better and provide these benefits

It can only be used for javascript and we had to find our own system for CSS combination like Velocity.
Not only Asset Pipeline helps in combining but compiling, compressing, finger-printing and gzipping from one command.

Compiling Assets

In Development:

We will serve all the files individually. Rails will automatically convert 'popup.css.scss.erb' to 'popup.css' and combine all the necessary files.

It won't compress or do fingerprinting.

In Production:

We do precompile assets by running the following command

'bundle exec rake assets:precompile RAILS_ENV=development SKIP_BCAPP_INITIALIZATION=true'

This will put all the including css, images and javascript into one folder under public/assets. This way we don't have to compile OnDemand which will make the processing very fast.

Engines

Engines are scale down version of an application which will have its own controllers, views and routing but can be deployed through a single app. eg.

Our acquision code can reside in a separate engine completely isolating the assets, views and controller and can be mounted on our main app and anything which goes to /acquistion will go to that engine. However, you won't need to deploy acquistion engine separately, it's get deployed with the main app.

App and Engine share the Gemfile, Boot and Environment

Engines can have their own controller, views helpers and assets

We still can share controller, views and helpers ( in some hackish way) if we need to with the main app (Core App)

Idea is going future, we will put Summer Sites and Acquistion into its own Engines and try to share smartly whatever we need. They both will have full access to

HTTP Streaming

This means that Rails will support chunking of the response, i.e. sends the response to the server as soon as it processes.
We already had that enabled in nginx and Apache but now supposedly Rails supports that as well which means that rails will write to stream as soon as it's done with rendering part of the template.
This can speed up if in our head tag css and javascript are defined. Those requests will get triggered as soon as Rails done with the parsing those lines while its processing rest of the pages.

Conclusion

After Rails 3.1 we should have much more organized assets
we can natively support SCSS and ERB processing of assets i.e. we can have javascript with 'popup.js.scss.erb'
We would have a good way to extract applications which heavily depend upon our backend but much different in front-end using Engines.

Just a quick note, we should try to use in our app all the rails helpers for generating tags eg. form_tag, image_tag, stylesheet_link_tag. Rails does some magic and add stuff to it and when we don't use them then we have manually mixin that magic either its detecting path or putting authenticity token etc.