How to have several output files with rails asset pipeline? - ruby-on-rails-3.1

I'm developing a rails app which handles a public area (as of today, static pages), and a private space with authentification, etc. Both of those were developed independently. The first has hand-made style, the latter uses twitter bootstrap.
In production, rails compile my assets into one file, and some styles are conflicting, resulting in the public area having some elements of Twitter Bootstrap... Not what I want.
Is there a way to configure the asset pipeline so when it compiles, there is two output ? the classic application.css, and the front.css?

Yes, there is. You need to have two manifest files. I would call the public one application.css and the private one admin.css as this is a common Rails convention.
The application.css should require all the public CSS files, and you will need to remove the require_tree directive as this is what is including things you don't want.
The second manifest file, admin.css, will include the things you want for the private side.
You can then reference these files in the layouts using the Rails helpers.
You will need to add the admin.css (and .js if there is one) to the precompile array for this to work correctly in production:
config.assets.precompile += ['admin.js', 'admin.css']

Related

Ember - where to put the public site

I'm wrapping up my Ember application and I want to figure out the best practice for handling the public site (/, /about, /faq, etc). Ideally the Ember JS and the majority of the app itself wouldn't be loaded.
There are a couple options, but I'd like to know the best practice.
Option 1 - Part of the app
Just make the public pages templates within ember-cli.
Pros:
Same asset pipeline
Single delivery of your entire site
Cons:
How do you have two base templates? One for the public site and one for the app itself. Ideally I'd be able to have different nav bars for each part. Everything inherits from the application.hbs template but I don't want to put conditionals in there to handle the two nav bars. I also don't want to overwrite every other page in my app to put it under a different template (/app/*).
The entire app would be loaded the first time the user goes to the page (only gets slower as the app gets bigger).
Option 2 - Part of the public folder
Create static HTML in the /public folder.
Pros:
Same asset pipeline
Single delivery of your entire site
Not loading the entire app for public pages
Cons:
You have the write the entire HTML for every page. This doesn't allow for quick development.
No template system. As the public site grows it's best to have a template so you can easily change the nav bar on all pages.
Not sure how to handle / since ember-cli wants to handle that url, but I'd want it to be apart of the public site.
Adds a lot of junk to your public folder since you'd need to add about/index.html for good urls.
Option 3 - Separate from the ember-cli project/app
Create a nanoc site or some other statically generated site and deliver it for your public pages.
Pros:
Have properly layouts for public site
Separation of assets
Not loading the entire app for public pages
Cons:
Need to figure out how to properly deploy separate apps on the same domain (putting ember-cli under /a/ is easy, but if I deploy to heroku how do I serve up multiple heroku apps on the same domain?).
How should /sign-up and /sign-in be handled? Public site with public site chrome, or web app with a signed out state (not ideal).
I would go with first opinion. About your questions about two base templates > you can hack it in router to show exactly what you want.
Here's the link about similar issue: https://stackoverflow.com/a/14231712/4560056
Separate.
Use your .htacess file or whatever the equivalent configuration mechanism is for your server setup to control when your app should have responsibility for serving content and when it should not.

How can I compile stylesheets dynamically in Rails 3.2?

I have an application with a subdomain for each customer. They can change the look and feel, which is all based on Twitter Bootstrap. When they save their settings, the app creates a .less stylesheet for them, where the appropriate Twitter Bootstrap variables have been set to their liking.
I the appropriate stylesheet in my application.html.erb file based on what subdomain was accessed. I know that won't work in production.
I'd like to invoke something to compile it as it is saved. Any thoughts?
It sounds like you need to be able to trigger Sprocket compilation of these files on demand during run time. I have no experience with it, but this guy has:
http://www.krautcomputing.com/blog/2012/03/27/how-to-compile-custom-sass-stylesheets-dynamically-during-runtime/

Serving up pages using Rack (PHP style)

How would I go about building a (small?) Rack app that serves Slim templates from say a "views" directory and static files from "static".
I've tried several frameworks that seem to do this, including -- Serve, Brochure, RackServerPages but they all seem to have their own issues.
Serve won't let you choose a layout
Brochure bombs on a "yield" in the template
RackServerPages won't let me pass locals while rendering a partial
Or is there a gem out there that does it already?
Thanks!
Try Stasis - It has layouts, controllers and local variables.

Rails 3.1/Sprockets: Injecting controller variables (or helpers) into javascript assets

I have an action with
def new
#test_var = 'i want this to show'
end
All I want to do is inject that into the javascript called for that page. For example:
#app/assets/javascript/my_model.js.coffee.erb
$ ->
console.log('<%= #test_var %>')
I'm guessing this doesn't work because that the coffeescript/erb is compiled before the controller is accessed...so, if I wanted to inject controller variables into a JavaScript file (client side - NOT accessed via ajax) in 3.1, how should I go about doing it?
I believe the problem is that you're thinking about the asset pipeline all wrong...
asset being the operative word.
It's not a view pipeline. Other things which are assets? images & css files, things which can be preprocessed and then served as-is. The erb/preprocessing of your assets doesn't occur on each pageload/request, rather it occurs on startup/filechange so in production said assets can be optimised, cached and served statically.
You could probably figure out a way to achieve it using Live Compilation (see section 4.2 of http://guides.rubyonrails.org/asset_pipeline.html) but as the docs say:
This mode uses more memory and is lower performance than the default. It is not recommended.
The bad answer would be 'inject the javascript into your view', but decoupling your javascript from your rails controllers/views is a good idea.
A better answer would be to have an asset folder containing all of your controller javascripts, and use some "what page am I on?" javascript to determine whether to run the code or not.
Here's some answers that explain various approaches to this:
Rails 3.1 asset pipeline: how to load controller-specific scripts?
Using Rails 3.1, where do you put your "page specific" javascript code?

Static web site generation

I need an easy way to generate static web pages so that I can serve them up with Apache or Nginx. Currently I am using SproutCore's build tool (Abbot) to generate static pages but that is a little bit cumbersome as it is designed for building SproutCore apps, not non-SproutCore HTML pages.
Here are my requirements:
Javascript must be combined and minified
CSS files must be combined
Each image / CSS / Javascript asset must have unique URL for better caching (query string isn't enough)
Asset URL should be different only when it really changes
Localization support thorough HTML, CSS, Javascript and image files
Nice template engine with layouts, partials etc.
Here are possible solutions I have found:
Create the site using Ruby on Rails, then get all resources using wget like http://usefulfor.com/ruby/2009/03/23/use-rails-to-create-a-static-site-rake-and-subversion/
Use Middleman: http://middlemanapp.com
Any thoughts on this?
After a longish evaluation process I have decided to use Middleman. It does the trick and I love its simplicity and the fact that I can use existing Rack components with it.
Best Regards,
Pekka Mattila
I'm the creator of Middleman and would be eager to help you get comfortable using Middleman. My main goal is to give users the power of Rails, but focused on static development. Some of the actual code of Middleman is simplified versions of Ab
Here's what I do:
Ruby on Rails 3 with the High Voltage Gem, which makes it easy
to serve a static page body using the common templates. It requires a
simple entry in the routes (and you can use namespaces to create a
hierarchy).
Apache reverse proxy to stand-alone Passenger (which uses nginx I
believe) to run the Rails app. This article describes how to
configure it.
Stand-alone passenger will read the URL, see if there is a corresponding file in /public with the .html on it, and serve that. If not found, it will invoke Rails and generate the page. In essence, page caching, with the option of publishing your URLs with or without the .html. There is a section in the Passenger docs about page caching specifically.
As far as combining and minifying js and css, here's a good stackoverflow thread.
Rails has excellent i18n/l10n support.
Rails template engine is very nice to work with. And you can use HAML if you prefer.
For your 3rd and 4th points, I'm a little confused. You want css and js combined, but then you want each to have it's own URL. In Rails, the "cache => true" directive on asset tags takes care of adding a query string parameter that changes when the content does, which is a fairly traditional scheme. I'm not sure what context you are working in where that would not work. Any CDN I've ever used works fine with that, as does an web server implementing the HTTP spec correctly. Anyway, changing the actual path or file in the URL would require changing all references to it. Maybe I'm misunderstanding?
Monkeyman has the template engine you need, I think. Think of it as Middleman's little Scala brother. Nowhere as mature or feature rich yet, but we'll get there eventually. The current incarnation supports HAML, Jade, SSP for layouts, Markdown for content and a couple of other things.
Without any special order
jekyll - quite simple
middleman - a lot of funcionalities
nanoc - a lot of funcionalities
stasis - use controllers
staticmatic
frank
gumdrop
ruby on rails + wget
ruby on rails + high voltage + apache reverse proxy
You should probably also checkout mod_pagespeed. It will at least give you this:
Javascript must be combined and minified
CSS files must be combined
Each image / CSS / Javascript asset must have unique URL for better caching (query string isn't enough)
Asset URL should be different only when it really changes
It won't give you this:
Localization support thorough HTML, CSS, Javascript and image files
Nice template engine with layouts, partials etc.
You can have a look at docpad. It's written in coffeescript and runs on Nodejs. It is document based, where you write some documents and layouts, it will compile them and write them in the out directory. You can write documents in a lot of languages via plugins
It also supports multiple level of file compilation. For example from eco to markdown to html.
Another great feature of it is that you can query on other documents being generated in a document. For example in the first page, you have something like this to get all blog posts:
database.findAll({url : /posts/})
Which will return all documents having posts in their url.

Resources