I'm building a simple website generator application in Rails 3.0. I'd like a "publish" action in a controller that works just like an ordinary "show" action, but instead, saves a page as an HTML file in the "public" directory instead of displaying it in the browser. That is, I'd like to use the Rails render mechanism to create a file instead of providing an HTTP response.
What's the best way to do this?
Should I simply add caches_page :publish to the controller?
Or use render_to_string and File.new?
You can use render_to_string method: http://apidock.com/rails/AbstractController/Rendering/render_to_string
You still need to respond from the controller though. Maybe redirect to the page you just saved?
I would go with page caching.
Then if you have editable content, the pages should be automatically generated. You could then write a system task which bundles them up as a web site.
see (whatever)/actionpack/lib/action_controller/caching/pages.rb for instructions.
I found that page caching using caches_page won't work for me because there is no way to show a notification or redirect to another page after caching the page. The method render_to_string (suggested by #Grocery) is the way to go. Here's the example controller code:
def publish
#article = Article.find(params[:id])
html = render_to_string(:template => "articles/template.html.haml", :layout => 'article' )
FileUtils.makedirs("#{Rails.root}/public/articles/") unless File.exists?("#{Rails.root}/public/articles/")
File.open("#{Rails.root}/public/articles/#{#article.filename}.html", 'w') {|f| f.write(html) }
respond_to do |format|
format.html # publish.html.erb
end
end
Related
I am using CarrierWave to upload static HTML templates to certain user profiles on my webpage.
I am trying to render the HTML file on the user's home page once they log in. The Path for the HTML file after uploading is:
/uploads/profile/curation/8/User_Content.html
I'm new to rails and I thought I'd just be able to
<%= render /uploads/profile/curation/8/User_Content.html %>
to get the html to render, but I guess that only works for partials, which this is not.
Any advice?
You can use render_to_string. Please have a look over here. http://russbrooks.com/2009/11/18/embed-a-static-hmtl-page-in-a-rails-view
In your controller you can redirect to the page you want:
redirect_to "/uploads/profile/curation/8/User_Content.html"
I'm AJAXifying an existing Rails 3.2 application, and some of the requests that are made from the client are better done asynchronously. To facilitate this, and to cut down on rendering time, I'm giving feedback to the user via alerts. I have a blank div in my application.html.erb file that I add alerts to as needed from certain controller actions like so:
def my_async_controller_action
#user = User.find(params[:id])
begin
##user.import
flash[:notice] = "Your data is being downloaded."
rescue Exception => bang
flash[:alert] = "There was an error downloading your data: #{bang.message}"
end
respond_to do |format|
format.js { render 'common/flashes' }
end
end
And my common/flashes file just uses jQuery to append the alerts to the blank div. While it works fine, I have never seen alerts delivered like this, only via redirects. Is there any unwritten (or written) Rails convention or rule that I'm breaking by taking this approach? Also, is there a way to instead do this as a respond_with? I can't see how I do two different types of rendering from a single line.
If the js file you are rendering has the same name as the action of your controller, you don't need a respond_to block.
However, since you are placing your js file in a common folder, to reuse among your controllers, you have to explicitly tell Rails to render that file. This is totally fine.
If your action only responds to js, you can use brackets instead of a do ... end block to make it a one liner:
respond_to { |format| format.js }
However, since you have to specify the name of the js file, this can get quite ugly, so you can omit the respond_to block and just do the following:
render 'common/flashes'
This, however, has the inconvenient that if your controller receives an html request, it will search for a file named flashes.html inside the common folder. This will most likely return a Template is missing error. If you want to fix that, you have to add some constraints to the format.
However, if your action also responds to html, then you should declare the block like this:
respond_to do |format|
format.html
format.js { render 'common/flashes' }
end
You don't need the format.html, but when you look at the code, you can immediately tell that it responds to both html and js requests.
Using a respond_with block to render different files isn't applicable in your case, since you are only rendering some javascript. respond_with is used to return some resource in various formats (html, json, xml). This article goes into a little more detail.
respond_to do |format|
format.js
end
I see no problems from the side of your controller.
Just be sure to use escape_javascript when rending in your .js.erb
I am writing a simple Rails3 application running in a sub URL that works well except for one problem. If I do not add a ".html" extension at the end of a URL for the "index" method of any of the controllers, the request returns a blank page. It does not matter which controller I request, the "index" method always returns completely empty, including if I curl the URL. I have an "index.html.erb" file in each of the controllers, with simple but complete HTML, and if I do include the ".html" extension in the URL, everything works fine. Here are some example URLs and their results:
http://my.application.url/appname/pages -- returns a blank page.
http://my.application.url/appname/pages.html -- returns the correct HTML page
http://my.application.url/appname/pages/new -- returns the correct HTML form
http://my.application.url/appname/pages/1 -- returns the correct HTML page
http://my.application.url/appname/pages/1/edit -- returns the correct HTML form
My routes file looks similar to this:
My::Application.routes.draw do
scope "/appname" do
resources :posts
resources :pages
root :to => 'home#index'
end
end
The applicable part of my controller looks similar to this:
class PagesController < ApplicationController
def index
#pages = Page.all
respond_to do |format|
format.html
end
end
...
end
As I said, the index method is the only one that is having this problem. I have tried everything I can think of, including adding My::Application.default_url_options = {:format => "html"} in application.rb (which works except when I need to do a redirect_to from the controller), and I am at a loss. The app is using Thin as an application server proxied behind Apache 1.3 (which I unfortunately cannot change, and this doesn't seem to be an issue anyway because hitting the Thin server directly results in the same problem). Any ideas would be much appreciated.
So, the answer seems to be that if the URL does not specify the .html extension, the application will serve out assets (from the asset pipeline) of the same name as the controller, at least while running in the development environment. Once I removed the [controllername].css.scss and [controllername].js.coffee files (both of which were unused anyway) that were auto-generated when I created the controllers from the assets folder, the application worked correctly. Just for kicks, I tried leaving them in and running rake assets:precompile, but the behavior persisted until the files were actually removed. This still seems counterintuitive, and I am contemplating filing this as a bug.
I am seeing a scenario where my locale parameter is getting duplicated once I step into a mountable app. My app looks like so:
#routes.rb
resources :blogs
scope "(:locale)" do
mount Auth::Engine => '/auth'
end
If I am at a blogs page and look at an auth link it looks like this /en-us/auth/signout which works well, but as soon as I load into any page rendered by the mountable app, for example the profile page /en-us/auth/myprofile', the sign out link now looks like /en-us/auth/signout?locale=en-us
I don't want the querystring getting cluttered, what is causing the app to correctly set the locale parameter and then duplicate it in the querystring?
my bet is that your application controller has something like:
def set_locale
# code here
end
def default_url_options
# code here
end
Since your engine controller inherits from application controller, set_locale may be triggered twice.
Potential Solution: Check if the code is in an engine, then don't trigger locale setting.
This can be done with: self.controller_path().split("/").first == engine_name
I had the same problem. I was setting the default url options on the controller (by redefining default_url_options or by using self.default_url_options=).
The solution was to use Rails.application.routes.default_url_options = instead.
I'm trying to test that "static" pages (they're ERB, but get cached), generated through rails, don't render any stray flash notices left over by the authentication system (Devise) or wherever else.
I've tried writing this controller spec, but it appears that response.body only renders the template, not its layouts?
describe "so that static caching can be used" do
render_views
specify "flash notices are not rendered" do
# edit: the following flash lines don't do anything
# it's not the right flash object, this one is intended for
# inspecting after request not setting before request
flash[:notice] = "flash boo"
flash[:error] = "flash boo"
flash[:alert] = "flash boo"
get :show, :page => 'privacy_policy'
response.body.should have_content('flash boo')
end
end
class StaticPagesController < ApplicationController
layout 'master'
def show
response.headers['Cache-Control'] = "public, max-age=#{6.hours}"
render "static_pages/#{params[:page]}"
end
end
I've tried changing to a layout which does render flash notices, and even inserting the text into the layout template, but can't make the spec fail.
Is there a way to ask rspec to render the template with the appropriate layouts as well?
Is a controller spec the wrong way to try and do this?
It seems out of place, as it's more to do with which layouts are being used, and their contents, but the rendering process starts at the controller, it receives the result, and I can manipulate the flash hash contents before rendering.
Versions:
rails (3.0.10),
rspec-rails (2.6.1),
rspec-core (2.6.4)
Thanks, Nick
Turns out this isn't the right approach. It should be an integration test (cucumber, request spec, etc) as it's testing several layers. That and rails doesn't seem to render the templates inside their layouts at this level.
So in integration test:
Set up a flash message by making a request to a controller which does nothing else (create a dummy controller & routing in your test code), then hit the page of concern and make sure the flash notice isn't rendered.
e.g. https://gist.github.com/1178383
It seems like a long way round but it will cover it.