Multiple incarnations of one Rails app
What's the best way to organize multiple, slig开发者_如何学Gohtly-varied incarnations of one Rails app?
The incarnations vary on css, images, database and domain. The app/logic is otherwise exactly the same. There is a chance public-facing path names of some routes will need to vary, but still the same route structure.
So I'm thinking of having one installation of the app and managing these changes in the environment.
DB is obviously already set up nicely for this. CSS and image paths I imagine would be easy enough to make environment-aware. Routes shouldn't be too difficult either I guess, in theory anyway.
The reason I'm writing this post is because I'm sure this problem must been solved. Is there an existing "skins" gem or something I can use for this? Otherwise, any comments on my planned approach would be greatly appreciated! I'm using Rails 3.
Why not just maintain separate branches in your revision control system?
A lot of it depends on why you're trying to achieve this. We currently serve four different 'apps' on a few different domains and subdomains from the same Rails Application. We do this because we have different clients that want to see different features of our product. For instance every product shares the idea of customers, contracts, merchants and many other models but they want to have the site branded differently, tab and menu items named differently and have some parts of the site inaccessible to certain people.
You've outlined CSS and images as your main concerns so I'll stick to those, however we've also had to employ ideas to remedy layouts, authorization and javascript amongst other issues and resources.
For simplicity sake I'll call a skin what in our case is a separate product.
Our app has a plugin that sets up some environment variables based on the incoming domain. Then based on these variables our Rails app will source different layouts and partials as appropriate. These layouts then reference the appropriate JS and images which are stored in locations that make sense for designers and frontend devs. For instance customer.js may store the usual customer operations, then in a sub directory there may be a customer.js for a skin and it will extend the main customer.js file (we use Dojo to do this).
In other areas where security is a concern we have libraries that do what is required based on the environment variables that were set by our domain gem.
We also have to provide dynamic branding so again these views and layouts have helpers with logic in them to determine where images should come from and so on.
For CSS we use SASS, so a lot of the time you can use mixins for colours and images. We do this by having a root SASS file with layout information that uses variables for colours and images. Then we'll require those colour files and image files into the root SASS as required.
The answer may be better if you give some information on how you are determining between these two skins. As far as I know there are domain plugins out there already that could help you determine which site the user is trying to access. As for how to organise your application to render the correct CSS, images, JS and so on hopefully what I've outlined helps a little.
精彩评论