What are the exact difference between the functionalities of app/View part and Public part of ruby on rails.
It seems that similar type of assets like js functions etc are defined in both.
what are the reasons behind defining the same things twice
In the public directory, Rails stores only static assets, i.e. files which are sent to the client as is without any further processing. These files can be generated using the assets pipeline (e.g. javascript assets or CSS files). However, they are only generated once (typically) during deployment.
The views however are the templates used by rails to generate the response to a dynamic request. Thus, if a user requests a certain (dynamic) action from your application, your controller decides which view to render. Its output is then sent to the browser. The view can thus be highly dynamic so that their output can change for each request.
Related
I have to embed an existing HTML project (a directory that was exported from another service including HTML files, gifs, and pngs) in a Rails app. These files should only be viewable by authenticated users, so I can't put them in /public.
Do I have to write a controller and convert all the existing HTML files (of which there are many) to rails views to get all the routing and auth to work and serve the assets via the asset pipeline? Or am I missing a less time-intensive solution? I'm worried that the HTML may change not-infrequently and I don't want to get stuck replicating this process often.
If you did not need to authenticate the user, then you would be able to serve them over the /public folder. But I think you will need controllers since you want to authenticate.
You will need to create controllers and views. It should not be too hard as you won't need to do a lot of custom erb.
Then just add a authenticate user before method to all pages you wanted authentication for.
In Rails, my assets have fingerprints added to them, e.g.
mysite.com/assets/something/base-216123123asdfasd20a.css
Unfortunately, if I want to link to this from another site (like a blog) I can't rely on the fingerprint.
Is there a configuration setting I can set so that I can access files without knowing their fingerprint? (While still keeping the fingerprint for normal Rails usage; this would just be used for special cases)
I don't want to do one-off things like creating a route for a specific asset, because I'll need it for many assets.
The simplest way is to put the files directly into the public folder:
- public
-- your_file.js
This would then have to be called by referencing your URL directly = http://domain.com/your_file.js
This is only really advisable for files which you want to remain static (such as widget JS or similar).
Non Digest Assets
Alternatively, you may wish to try a gem I've never used before called non-stupid-digest-assets - a gem which allows you to determine which files are "fingerprinted" and which are not.
I've never used this gem, so cannot comment on its effectiveness, but it looks like it will give you the ability to save certain assets without their fingerprinted name. This means that you'll still be able to call them using the various asset path helpers which are available in Rails, as well as giving others a direct reference for the file:
#config/initializers/non_digest_assets.rb
NonStupidDigestAssets.whitelist = ["your_file.js"]
You'll then be able to call asset_path("your_file.js")
I want to know if there is a way (or a gem) that can compile me a Rails application into a static web site; I have some files that need to only be compiled once (i.e. they have no dynamic content but they need to be parsed at least once). I can't seem to find any way to do that so I have a feeling that it might not even be possible.
I don't believe there's a way to do that with an entire Rails app. That's more the territory of https://github.com/mojombo/jekyll or https://github.com/imathis/octopress. If it's only a few pages you can use caches_page :page1, :page2, ... in your controllers. That will write the fully-rendered page to public/ so that it can be served directly by Nginx/Apache on subsequent requests.
Edit In Rails 4 you'll need to use the actionpack-page_caching gem.
I need to localize an app, so I created a file for Spanish translations, but the config/locales/es.yml file doesn't seem to be properly loading, or maybe it loads after my templates are evaluated.
First a little context, I'm using the handlebars_assets and haml_assets gems. The latter allows to use the ActionView helpers within the templates in the asset pipeline and it also has access to the application classes, so one could write templates like:
.some_div
= SomeModel.model_name.human
And it works, except that it's returning the fallback name of the model. If I make these kinds of translations in a view though (instead of .hbs.haml template) I get the proper translated string. This is also true if I execute the translation methods in the rails console.
Following the Rails Guides I created the following initializer:
I18n.default_local = :es
Which is working properly if I consider that translating in views renders the expected output. My application is mostly living on the client side, so I really don't use Rails' views, it's a single page application managed with the help of Backbone. All the UI lives in templates that get rendered through the asset pipeline. So my question is, has anyone managed to make I18n work with this setup?
I have a rails application with static content in the public directory (e.g. public/index.html) and additional static content in nested subdirectories (e.g. public/one/two/index.html).
All the static content is served correctly if I run it locally via script/server but when I upload it to Heroku the top-level page loads correctly but the nested content returns a 404.
I've found a number of resources (for example this question) which discuss static content in rails but they all seem to assume a fairly simple structure with a single directory containing all the files.
Is there any way I can fix this?
If you have a very simple web application (with mostly static content, say) then using Sinatra on Heroku is much simpler to set up and prevents this type of problem.
You can serve up static content on Heroku without writing any "code" at all... you just need to tell the "Rack" middleware where the content is (as detailed in this help article):
http://devcenter.heroku.com/articles/static-sites-on-heroku