What's considered an "asset" in the Ruby on Rails universe?
Are user generated files, such as images uploaded by the user, considered assets? Where should they be stored in the standard file structure of a Rails project? Should they be kept clear of any asset related directories like:
app/assets
lib/assets
public/assets
Relevant: The Asset Pipeline
Generally asset is anything that browser loads after it gets the HTML page. Meaning javascript, css and any images. But as you pointed out there are two different image types in a rails project.
1) the images related to your css and layout design, those go under the app/assets/images
2) the images that your users upload, those normally go into the public/system or public/uploads folder depending on what you use to receive the uploads
The lib/assets (or sometimes vendor/assets) is where you supposed to place js/css/images related to your front-end design and provided by third party libs. Say if you want to pull in some css or a js framework, that were you should place it.
And finally public/assets is where rails will compile your layout assets from the app/assets and vendor/assets folders when you run rake assets:precompile task for production.
To have it short, your design stuff goes to app/assets, and the user uploads go into public/system
User-uploaded files are not part of assets, and should definitely be kept clear of asset-related folders. You should put them somewhere in your public directory. I put mine in public/uploads, which is a common convention. And then you should ignore those files in git (or whatever VCS you're using).
Assets are basically: javascript, stylesheets, fonts, and images which are part of the site design itself, not part of the user-uploaded content.
Related
The Rails guide here says
"Any assets under public will be served as static files by the
application or web server when config.serve_static_files is set to
true. You should use app/assets for files that must undergo some
pre-processing before they are served."
I'm using Rails 4.2.4. There is no public/assets folder. This leaves me wondering a few things:
What is meant by "use app/assets for files that must undergo some pre-processing before they are served?"
What is meant by pre-processing?
How is a static asset different from other assets, and what are the performance benefits of using one pipeline over the other?
Do I even need to worry about this if 4.2.4 has no public/assets folder?
Assets like javascript/css etc. need to be pre-processed - eg. minified, hashed for cache busting, passed through transpilers (like coffeescript) etc. Such assets should be kept in app/assets folder.
I believe 1 already answers that.
Passing each asset through transpilers/minifiers etc. as described in 1 during production will be very expensive and wasteful - because these assets don't change dynamically we can just do them once during pre-compilation and let static file server or cdn handle their delivery.
When you precompile your assets in deployment, the compiled files will be generated into the public/assets folder.
I recommend reading this article, which explains asset pipeline in much detail.
I have a question relating to how precompiled assets are utilized in a production environment. What about general file attachments as a part of the model? For example, I have the model "Event". You can have n attachments to the model, and they can be any file you want. Typically they are either image files or PDF files, but they can also be Excel files for example. These files are to be displayed as links to the user and the user can click the link to open the file. The attachment files are stored in the /assets directory in the following manner, alongside the standard assets:
/assets
/images
/javascripts
/stylesheets
/attachments
/events
/11
poster.jpg
event-details.pdf
Now as I understand it, when I run the precompile method, Sprockets generates gzipped/MD5'ed versions of the files to be served...how do I deal with these attachment files? If I run the precompile method, everything gets gzipped...but when I add/remove attachments further down the road through the web interface, some will be gzipped and others won't. What's the best way to deal with this?
I gave up trying to figure out a way around it and just set all the attachments as well as paperclip attachments to be physically put in the /public directory. From my vantage point, this removes the benefit of compressed assets, but whatever.
I have compiled assets using following command in rails 3.2 for production purpose.
RAILS_ENV=production bundle exec rake assets:precompile
After running above command an assets a folder is created under public. Now I want to removed non-compile assets folder because it is huge. But I have need answers to following questions.
Do I need the assets folder that contains non-compiled assets ?
If yes then what is purpose of having a non-compiled assets folder ?
I will appreciate your help.
Yes, keep them.
The purpose is that when they are taken from assets to public they are usually minified and combined, greatly saving space and helping to reduce download time for end users when using the site. But when you need to make changes, use the originals in assets.
In development mode (local, on your box), the assets version is used and is useful in traces while developing/debugging as they point to the actual source code lines in question and have the original (usually longer and meaningful) variable names.
Most likely you will need to make changes to one of your assets in app/assets in the future.
app/assets has the original source files with original formatting and these are the files you should change.
Theoretically you could delete the source files in app/assets, but then you won't be able to change anything and re-compile with those changes.
After I deployed my upgraded Rails 2.3.x -> 3.1 (rc4) app to our test environment this afternoon, all of our stylesheets and JavaScript files were returning 404 errors. We had added the rake assets:precompile task to our post-deploy script and it took a while to determine why the assets folder didn't have the pre-compiled files we expected.
In the end, the files weren't being compiled because apparently only application.css and application.js (+ non JS/CSS files) are processed by default.
We needed to change the following configuration value as follows:
config.assets.precompile += %w( *.js *.css )
Question: why isn't this the default?
I would have expected that anything that wasn't necessary to process as a manifest file would just get copied into public/assets. Much of what I've read on the asset pipeline is essentially "stick your assets in app/assets, configure the manifest files, and it should just work". Since the assets:precompile task didn't spit out any information about what it was doing, it took a while to determine that it just wasn't looking at the files we thought it would.
Is there any reason why this would not be a good value for the precompile configuration?
Thanks!
The idea is to have all your JavaScript and CSS always loaded in one shot, rather than loading bits and pieces as you move along. That way you always have the 'world' loaded and ready to work with, rather than having to include a whole bunch of individual files here and there.
It's a bit of a larger 'up front' load, but then the browser should keep loading all the javascript from cache. So the perceived speed of the site should speed up due to having everything cached and ready to go after the first request.
This was a controversial decision to include for Rails, but so is including CoffeeScript by default. Rails has always been an opinionated framework that way.
the new sprockets-based pipeline compiles all the files in /asssets/stylesheets and /assets/javascripts get compiled into application.css and application.js, respectively, by default.
In your views, you only need to link the application files, sprockets handles the rest.
Update:
Well, you don't have to make it all into just one file... You could have an shared.js, secure.js and public.js and have them each include the parts they need...
Think of them not as javascript files, but manifest files that establish groups of javascript files which you can then include as a group with a single javascript_include_tag. While the default is to include everything in the folder into a single file, you can be always pick and choose what to include, and what not.
The 'precompile' task simply runs those manifest files and compiles the multiple files into one, while pre-processing and sass or coffee script it runs across.
With the introduction of the new directory structure in 3.1 (i.e. app/assets/), should app images (logo, banner, icons, main bg, etc) still be stored in public/images or should they go into app/assets/images?
Someone mentioned:
I would be shocked if anything in
app/assets can be served publicly -
that wouldn't make sense from either a
security viewpoint or from honoring
the convention of the public
directory. Since you need these flash
files to be publicly accessible, you
should store them in public.
Valid point. Which brings me to the question:
Based on above understanding. What about the app images? If images such as logo, banner, main background, icons are considered public, why is there an images directory in app/assets?
Or should we still put these types of images in public/images. If so, what is the images dir in app/assets used for?
Note: I haven't looked at Rails 3.1 yet...
As far as I understood DHH's keynote, app/assets was introduced so you could structure your application in a better way. But there's nothing wrong with storing images in public/images. Thanks to Michiel for pointing out that public/images will no longer be with us in Rails 3.1!
The public folder will the replaced by the assets folder. That's the folder that your web server will point to. Files from app/assets, lib/assets or other places will be copied (images) or compiled (css, js) to assets.
That means that assets is now considered a build directory, and you shouldn't store anything there - you might even decline to put it under version control, and just have the server generate or copy the images and css and scripts when you deploy.
See also: http://blog.nodeta.com/2011/06/14/rails-3-1-asset-pipeline-in-the-real-world/