wicked_pdf handlebars/mustache support - wicked-pdf

I've used wicked_pdf with erb before, but I'm now wanting to use wicked_pdf leveraging handlebars as my template engine.
Should that just work with wicked_pdf? I see questions with haml tags, so I'm assuming yes. Just wondering if anyone else has tried.
On a side note - Is anyone using presenters with wicked_pdf?

It should work.
WickedPdf merely hooks into the Rails 'render' method, so anything it can do, can be done with wicked_pdf.

When I use haml I do the following, perhaps something similar is possible with handlebars.
def [action-name]
...
respond_to do |format|
format.html
format.pdf do
render :pdf => 'filename',
:handlers => [:haml]
end
end
end

Related

Is there any issue with using respond_to blocks in controller actions like this?

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

recaptcha_tags rendering escaped HTML in erb

I'm migrating my app to Rails 3.2.8 from 2.3.5. One form uses reCAPTCHA (in an erb file). Right now, all the HTML tags that the recaptcha_tags puts out are in escaped HTML. (i.e. <...> instead of <...>). So I see the tags themselves in the HTML page, instead of the reCAPTCHA box.
Here's what my erb looks like. I've verified that it doesn't matter where in the erb I put the recaptcha tags (inside the form_for or outside):
register.html.erb
...
<%= recaptcha_tags :public_key => RECAPTCHA_PUBLIC_KEY %>
...
Other things, like form_for don't have this problem. They output straight HTML.
Gemfile
gem "recaptcha", :require => 'recaptcha/rails'
Thanks in advance!
Turns out I needed to prefix the recaptcha_tags call with "raw":
register.html.erb
...
<%= raw recaptcha_tags :public_key => RECAPTCHA_PUBLIC_KEY %>
...
One of the major changes between Rails 2.3.5 and 3.X was some changes having to do with cross site scripting. You may want to start your upgrade by upgrading to 2.3.14 and adding the rails_xss gem. The rails_xss gem (https://github.com/rails/rails_xss) will switch the HTML safety default to escape, so it will cause the issue you're seeing with recaptcha_tags. This will allow you to see what strings in your app need to be marked as html_safe.
Or, if recaptcha_tags is the only issue, you may be able to fix it by telling rails not to escape the recaptcha_tags.
Something like:
<%= raw recaptcha_tags :public_key => "_________" %>
Thanks for doing the research. :)

Rails 3 + Devise 2 + JsonP / Callbacks

I'm working on a PhoneGap mobile app that communicates with a rails3 server using a REST api and json. Authentication is done using devise 2.0.4.
For my own controllers I can specify that rails should wrap the json with the callback to handle the Cross-Domain problem by the following:
respond_to do |format|
format.html # index.html.erb
format.json { render :json => #books, :callback => params[:callback] }
end
notice the:
:callback => params[:callback]
I'm unable to do that with the devise controllers.
How can I get devise to respond to js requests - i.e. json with a callback?
Thanks a lot,
Ariel
It would be better to override devise controllers providing the :callback parameter to renderer or using before_filter somehow. In order to do that copy devise controller(s) from github/local-gem-directory to your app and then edit. But it would be much easier to define a JS views for each action:
If you ain't done it already start with generating devise views (which is not necessary but would help you to get the idea):
rails g device:views -s
It would generate lots of *.html.erb files inside of your app/views/devise folder. You have to create appropriate *.js.erb next to them with following contents:
<%=render :inline => params[:callback]+'('+resource.to_json+')'%>
PS: Actually you may just put that line into app/views/application.js.erb and skip other steps;)

Rails is responding with wrong format

I have the following action:
def something
# do something
respond_to do |format|
format.js
end
end
I also have an something.html.erb template in my controller.
When I GET /controller/something, it returns nothing.
When I GET /controller/something.js, it renders the html with no layout.
When I XHR GET /controller/something, it renders the html with no layout.
I would expect it to "return a template not found error" error instead of rendering the html template.
Is this a bug of Rails or am I doing something wrong?
rails v3.0.4
ruby v1.9.3
I think it's because of the “convention over configuration” principle. If you don't specify a render or redirect_to in the action of the controller, rails renders the view with the same name as the method. Look at Rails render guide

Render a page as a saved HTML file using Rails 3.0?

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