What does it mean when nobody replies after almost a week? Does that mean everyone thinks it's a good idea or everyone thinks it's a bad idea? Should I just take my chances and submit a PR?
On Friday, July 31, 2015 at 10:05:44 AM UTC-4, iybe...@gmail.com wrote: > > https://github.com/rails/sprockets-rails/issues/49 (which is locked so no > further discussion is possible there) debates whether asset precompile > should create a non-digest version of the assets. > > There are a few valid use cases for this, and I do not have solutions for > all of them, but I just thought of a solution to one--static error pages. > > @pelargir, in some of the first comments on the issue ( > https://github.com/rails/sprockets-rails/issues/49#issuecomment-20529994, > https://github.com/rails/sprockets-rails/issues/49#issuecomment-20531267), > stated the issue: > > > Removing generation of non-digest files also makes is impossible to have > static 404 error pages that use the same images, JS, and CSS as the > remainder of the site (without making duplicate non-digest copies of those > files in /public). But then I end up with two copies of the same file in my > app. > > Am I supposed to copy the precompiled file into /public and remove the > fingerprint from the filename? So then, if I change the file in the future, > I have to precompile, copy, and rename all over again? > > My idea is to make the static error pages part of the asset pipeline. > Instead of generating public/500.html, public/404.html, etc, a new rails > app should generate app/assets/html/500.en.html.erb, > app/assets/html/404.en.html.erb, > etc. "app/assets/html/*" should by default be included in > config.assets.precompile (which I believe it is anyway since it's in > app/assets and the extension is neither .css or .js). > > There are 2 places where the behavior would be significantly different > than of all other assets, so things would get a little tricky here: > 1) Unlike other assets, these would need to be precompiled in the context > of a layout. This could be either the same application layout as the rest > of the application (app/views/layouts/application.html.erb ), or the "rails > new" generator could create a separate > app/assets/html/error_layout.en.html.erb (which itself should be excluded > from precompiled). Telling sprockets when to compile in the context of a > layout could be tricky, but an alternative is just to code that into the > view. Below is an example from an existing project of mine. It's in HAML, > not ERB, but still illustrates the point: > > # app/assets/html/500.en.html > - layout = Rails.root.join("app", "assets", "html", > "error_layout.en.haml") > = Haml::Engine.new(File.read layout).render do > %h5 We're sorry, but something went wrong. > %p Our developers are working on it. > > 2) Error pages currently live in public, but with this approach, they > would end up in public/assets, and would have digests in their file names. > So we would need to change > https://github.com/rails/rails/blob/v4.2.3/actionpack/lib/action_dispatch/middleware/public_exceptions.rb#L44 > > to look in "public/assets" and use the appropriate digests, and add a > Depracation warning (that shows up in development environment) if the error > pages are found in "public". > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
