I came across the view helper function "provide" today. By looking into its manual I am still confused on how it is different from "content_for".
provide(name, content = nil, &block)
The same as content_for but when used with streaming flushes straight
back to the layout. In other words, if you want to concatenate several
times to the same buffer when rendering a given template, you should
use content_for, if not, use provide to tell the layout to stop
looking for more contents.
Question 1: this is quite abstract to me - could anyone flesh it out by giving a demonstrative example?
Question 2: working with asset pipeline, which performs better and why?
Thanks!
First of all, what is streaming? Why would you use it?
Streaming is alternate method of rendering pages top-down (outside-in). The default rendering behavior is inside-out. Streaming must be enabled in your controller:
class MyController
def action
render stream: true # Streaming enabled
end
end
According to the documentation:
Streaming may be considered to be overkill for lightweight actions
like new or edit. The real benefit of streaming is on expensive
actions that, for example, do a lot of queries on the database.
So, if you're not using streaming, is there still a difference?
Yes.
The difference is a template can define multiple content blocks by calling content_for multiple times. Doing so will concatenate the blocks and pass that to the layout:
# layout.html.erb
<div class="heading"><%= yield :surprise %></div>
<div class="body">
<p><%= yield %></p>
<p>But it's not very interesting...</p>
</div>
# template.html.erb
<%= content_for :surprise, "Hello" %>
I've got your content!
<%= content_for :surprise, ", World!" %>
# Generated HTML
<div class="heading">Hello, World!</div>
<div class="body">
<p>I've got your content!</p>
<p>But it's not very interesting...</p>
</div>
Since provide doesn't continue searching the provided template, only the block passed to the first provide call will be sent to the template:
# layout.html.erb
<div class="heading"><%= yield :title %></div>
# template.html.erb
<%= provide :title, "Foo" %>
<%= provide :title, "bar" %>
# Generated HTML
<div class="heading">Foo</div>
Was curious to see what the difference was, and as Thong Kuah pointed to the api, inside the answer:
This means that, if you have yield :title in your layout and you want to use streaming, you would have to render the whole template (and eventually trigger all queries) before streaming the title and all assets, which kills the purpose of streaming. For this reason Rails 3.1 introduces a new helper called provide that does the same as content_for but tells the layout to stop searching for other entries and continue rendering.
Related
Reviewing some starter courses, I see that the terms are used separately, but I think I only understand layout. To my knowledge the layout is a temporary portion of code (such as a right navigation section, a div containing an ad, or something similar), and a partial is a partial template, but what is a template, and how does it differ from a layout?
Can you give a definition of all three with relations to each other if possible? (ie a template is .... and there are two kinds, partials and layouts.... layouts are specific types of templates or whatever the answer is)
Please correct my assumption if needed...
In Railscasts 294 using pjax, layouts are explicitly differentiated by the random number generator, and this is why I got lost.
I am trying to make a single page accessed by App/Verb/noun, where i can either "capture" or "display" "photos", "videos", "images", etc...(app/captures/photos or app/captures/videos or app/displays/photos etc) and am trying to make just one div change based on when I "capture" different things.... and I am getting lost in the verbiage, or I get really close but am not really understanding what im doing.
I know this is an old question, but I've wondered the same. In the guides, there is no clear explanation of the difference between layouts and views, nor is there a clear explanation of the relationships. To add to the confusion, the term 'template' is often used for both. As someone that was programming Smalltalk in the 90s (but is new to Rails) I deeply understand MVC and understand some of the many ways that it an be implemented -- so my confusion wasn't with that part. There's just a missing piece of context about views, layouts, and templates and how they relate to each other.
Here's how I came to understand it:
Start with a simplistic understanding and example so that the relationship and role of each part is clear:
a view is 'stuff to be displayed' for a particular controller to respond to an action (which puts it into a particular state). A view is a snapshot of your model at in a particular state, for a particular action (reason/context). It's about information and state, not necessarily about 'looking good'.
a layout has specific information on how something will be displayed. It may have markup (CSS, HTML, etc.) that provides instructions on how something will be organized (this part up here, that part over there, those go at the bottom, these float at the top; that is navigation information, this is H1, that's H3, this is a definition..) and how it will look (left, right, up, down, red, green, emphasized, flashing, hidden, big, tiny, Helvetica, etc.)
Think "Layout and Looking Good"
Say you have a Contract model and controller, and you have a file that defines the view: view/contracts/show.htm.erb:
<% content_for :full_identification do %>
<p><%= contract.display_name %> <%=contract.full_id_number %> </p>
<% end %>
<% content_for :summary do %>
<p> This is the summary for <%= contract.simple_name %>. You hire us. We give you coolness. You pay us.</p>
<% end %>
<% content_for :client_info do %>
<div class="client-info">
<p><span class="contract-title">Client: <%= contract.client_name%></span></p>
<p>Address: <%= contract.client_address%></p>
<p>Phone: <%= contract.client_phone %> </p>
... more info about the client....
</div>
<% end %>
<% content_for :scope_of_work_statement do %>
<p class="scope-of-work-statement"><%= contract.scope_of_work%>:</p>
<% end %>
Your layout file would have more details about the HTML (assuming HTML output) and specifics about how you want things to look. Maybe you have a controller and view that is specific for what (and how) the client sees that contract. You have a layout file for that specific controller and it looks like this:
layouts/contracts/contracts_clients_view.htm.erb
<div class="tab-pane fade in" >
<div class="span7 highlight >
<%= yield :full_identification %>
<div class="no-breaks reflow" >
<%= yield :summary%>
</div>
</div>
<div class="span5 scope-of-work-statement">
<h3>Scope of Work Statement</h3>
<%= yield :scope_of_work_statement %>
</div>
</div>
</div>
*[This is a totally contrived example so that I can make the relationship between view and layout clear. Obviously things would be modeled and expressed differently in the real world. ]*
The view provides input (the content pieces) to the layout.
Views are for controller actions and are named accordingly. (Ex: show, edit, index, etc.)
Layouts are named for the controller used to render them. (Ex: application -- for the ApplicationController, contract -- for a ContractController, contract_customers_view -- for a ContractCustomersViewController)
Where it starts to get tangled is that a view can also have layout information in it. Sometimes there is only the view file (no layout file). And either one can be written in a template language (like ERb or HAML) and thus they can both referred to as a template.
A partial is really just what it says: it's just a piece that can be used (and hopefully re-used). You can take part of a view or layout and re-factor it so that you can re-use it -- now it's a partial. Common uses of partials include the head section, navigation sections (including header, footer, etc.), places where you can re-factor for reusability, and improving coding style and readability by using them for semantic and logical sections. (That's why people liken them to a subroutine.)
Another place where you can get some context about views and layouts and how they're different is in the steps (flow) that ActionView goes through to actually produce output -- to render something using all of these pieces. It is important to understand when a layout is (or isn't) created, for example, so you understand which variables and parameters are or aren't available to you at a particular time.
(I'm working with Rails 4, btw.)
Given all of that, now imagine that all of your layout information is in your views, and that your views are written in a template language (ERb, HAML, etc.), and that you've used partials to make everything sing better. You may not have any layout files beyond one main one for your application that has a big yield in it where the real content (generated by your controllers & models) goes.
Hope this helps someone else get a handle on views and layouts. (And I suppose I should suggest putting something like this into the guides.)
From http://www.tutorialspoint.com/ruby-on-rails/rails-layouts.htm : A layout defines the surroundings of an HTML page. It's the place to define common look and feel of your final output. Layout files reside in app/views/layouts.
Template is a general term for the view files. A view template - residing in app/views/ folder - would be rendered within a layout.
Best resource to understanding how Rails views work is the Ruby on Rails Guides page on Layouts and Rendering : http://guides.rubyonrails.org/layouts_and_rendering.html
What is a layout?
(a) Let's start with the problem we are trying to solve
You might have 1000s of different "pages"/views on your rails app. All 1000 of those pages/views share the same headers, and footer. Now imagine you had to change the footer for your site: you would have to make that change in 1000 pages! What a nightmare: this is not efficient.
You can extract the headers and footers and place it in a layout.html.erb file which can be used by all 1000 pages. In that way: 1 change in one place can propagate to all 1000 of your views/pages. So if you want to change your header/footer you only need to make that change in ONE place, and that will be applied to all views that utilise that relevant template.
# example of a layout
# app/views/layouts/application.html.erb
<!DOCTYPE html>
<-- THIS IS SIMPLIFIED - DO NOT COPY this example -->
<html>
<div>
<%= yield %> <-- Notice the yield statement -->
</div>
</html>
# example of a view:
# users#show.html.erb
<-- This uses the application.html.erb layout -->
<-- Notice how I don't have to create a html tag - because this has already been created in the application.html.erb -->
<div class="container">
<h1> About <%= #user.full_name %> </h1>
<br>
<p>
<b> Name: </b> <%= #user.full_name %>
</p>
<p>
<b> Organisation: </b> <%= #organisation.name %>
</p>
<p>
<b> Email: </b> <%= #user.email %>
</p>
</div>
The rails app firstly renders the layout, and then yeilds to the specific views that you want to display. Now you can change the layout and have it propogate through to all your subsequent "views" which utilise the layout.
For example: content_for(:stuff) vs yield :stuff
I know they are implemented slightly differently, but is there any real functionality difference?
Is there a generally accepted best practice?
yield is how you specify where your content areas is going to go within a layout. You might have something like this:
<div>
<h1> This is the wrapper!</h1>
<%= yield :my_content %>
</div>
content_for is how you specify which content is going to be rendered into which content area. You might have something like this:
<% content_for :my_content do %>
This is the content.
<% end %>
The result would be
<div>
<h1> This is the wrapper!</h1>
This is the content.
</div>
They are opposite ends of the rendering process, with yield specifying where content goes, and content_for specifying what the actual content is.
Is there a generally accepted best practice?
The best practice is to use yield in your layouts, and content_for in your views. There is a special second use for content_for, where you give it no block and it returns the previously rendered content. This is primarily for use in helper methods where yield cannot work. Within your views, the best practice is to stick to yield :my_content to recall the content, and content_for :my_content do...end to render the content.
yield:
yield identifies a section where content from the view should be
inserted
content_for:
The content_for method allows you to insert content into a named yield
block in your layout. For example, this view would work with the
layout that you just saw:
yield :stuff will grab the contents that are pushed by content_for(:stuff)
So, using yield you can define the sections in your view/layouts and you use content_for for adding contents to those sections. Any unnamed yield will grab all other contents.
You can learn more about it reading the tutorial.
Calling #content_for stores a block of markup in an identifier for later use. In order to access this stored content in other templates, helper modules or the layout, you would pass the identifier as an argument to content_for.
yield can still be used to retrieve the stored content, but calling yield doesn't work in helper modules, while content_for does....more: http://api.rubyonrails.org/classes/ActionView/Helpers/CaptureHelper.html#method-i-content_for
From the Ruby on Rails API:
Calling content_for stores a block of markup in an identifier for later use. In order to access this stored content in other templates, helper modules or the layout, you would pass the identifier as an argument to content_for.
Note: yield can still be used to retrieve the stored content, but calling yield doesn't work in helper modules, while content_for does.
You can then use content_for :not_authorized anywhere in your templates.
<%= content_for :not_authorized if current_user.nil? %>
This is equivalent to:
<%= yield :not_authorized if current_user.nil? %>
content_for, however, can also be used in helper modules.
https://api.rubyonrails.org/classes/ActionView/Helpers/CaptureHelper.html#method-i-content_for
I am in ruby 1.9.2, rails3.
So My website has some structures,
and I want to put menu in a middle of my webpage.
I am doing something like (within application.html.erb file)
blahblahblah
<div id="menu">
<%= yield :menu %>
<div>
blahblhablah
I have a file menu.html.erb which has menu structure for the site.
What can I do if I want to use a file within ./layout folder to be used to be part of that yield :menu? I was wondering, if I have to use content_for for every controller, and within every functions...
Btw, menu.html.erb will be different for each controller, so thats why I am yielding it.
In conclusion, I just want to include one common shared menu.html.erb pretty much everywhere.
You could do something like this in your views:
<% content_for(:menu) do %>
<%= render :partial => "/layouts/user_menu.html.erb" %>
<% end %>
You could try to combine this with controller.controller_name (not sure this works for Rails3) and load a different menu for each controller automatically.
You might consider watching the railscast on layouts, it's concise and helpful.
Numbers 7 and 8.
http://railscasts.com/episodes?search=layout
Warning: Noob here.
I know this is a trivial subject but I'm having a lot of difficulty in figuring out how exactly I can simplify my views by moving parts of them into helpers. For example, I've always read that conditionals in your views are prime candidates for extraction into helpers, but I couldn't really find examples of this, and my attempts to achieve this failed.
For example, suppose I have:
#index.html.erb
<% for beast in #beasts do -%>
<% if beast.dead? -%>
<%= beast.body %>
<%= link_to "bury", bury_beast_path( :id => beast.id ) %>
<% else -%>
<%= beast.body %>
<%= link_to "kill!", kill_beast_path( :id => beast.id ) %>
<% end -%>
<% end -%>
It annoys me a little to have this in my view, but how exactly could I move this to a helper instead? And further simplify it, if possible. (I've read somewhere that conditionals are bad but it's just beyond me how you could program anything without them.)
Another example: I need to id my body tags with the format controller_action. The best I've got so far is this:
#index.html.erb
<body id="<%= controller_action %>">
…and…
#application_helper.rb
def controller_action
#id = #controller.controller_name + "_" + #controller.action_name
end
I'm no expert, but that's still ugly even to me.
To make things more complicated, Ryan Singer said something I liked: to treat ERB like an image tag, using helpers to "reveal intention". Then in the next breath saying that you should have no HTML in helpers for that is the way to hell. WTF? How are both things compatible? If it's come to the point where you can just declare behaviors in the view, surely there should be a lot of HTML to be rendered behind the scenes? I can't grasp it.
So, that's basically it. I'd appreciate if anyone could share some thoughts on this, or point me to some good in depth reading on the subject – which I've found to have a really weak coverage on the web. I've already googled it to exhaustion but who knows.
Refactoring makes your views easier to maintain. The problem is choosing where the refactored code goes.
Your two choices are partials and helpers. There's no stone-set rules dictating which should be used where. There are a couple of guidelines floating around like the one stating that helpers should not contain HTML.
Generally partials are better suited for refactoring sections that are more HTML/ERB/HAML than ruby. Helpers on the other hand are used for chunks of ruby code with minimal HTML or generating simple HTML from parameters.
However, I don't agree with the sentiment that helpers should contain no HTML at all. A little is ok, just don't over do it. The way helpers are processed hinder their use for producing large amounts of HTML. Which is why it's suggested that your helpers contain minimal amounts of HTML. If you look at the source the helpers that ship with rails you will notice that most of them generate html. The few that don't, are mainly used to generate parameters and evaluate common conditions.
For example, any of the form helpers or link_to variants fit the first form of helpers. While things like url_for and logged_in? as supplied by various authentication models are of the second kind.
This is the decision chain I use to determine whether to factor code from a view into a partial or helper.
Repeating or nearly identical statements producing a single shallow html tag? => helper.
Common expression used as an argument for another helper? => helper.
Long expression (more than 4 terms) used as an argument for another helper? => helper.
4 or more lines of ruby (that is not evaluated into HTML)? => helper.
Pretty much everything else => partial.
I'm going to use the code you're looking to refactor as an example:
I would refactor the view in the question this way:
app/helpers/beast_helper.rb:
def beast_action(beast)
if beast.dead?
link_to "bury", bury_beast_path(beast)
else
link_to "kill!", kill_beast_path(beast)
end
end
app/views/beasts/_beast.html.erb:
<%= beast.body %>
<%= beast_action(beast) %>
app/views/beasts/index.html.erb:
<%= render :partial => "beast", :collection => #beasts %>
It's technically more complicated, because it's 3 files, and 10 lines total as opposed to 1 file and 10 lines. The views are now only 3 lines combined spread over 2 files. The end result is your code is much more DRY. Allowing you to reuse parts or all of it in other controllers/actions/views with minimal added complexity.
As for your body tag id. You should really be using content_for/yield. For that kind of thing.
app/views/layouts/application.html.erb
...
<body id="<%= yield(:body_id) %>">
...
app/views/beasts/index.html.erb
<% content_for :body_id, controller_action %>
...
This will allow you to override the id of the body in any view that requires it. Eg:
app/views/users/preferences.html.erb
<% content_for :body_id, "my_preferences" %>
The first thing I'd do would be this:
#index.html.erb
<%= render #beasts %>
#_beast.html.erb
<%= beast.body %>
<%= link_to_next_beast_action(beast) %>
#beast_helper.rb
def link_to_next_beast_action(beast)
if beast.dead?
link_to "bury", bury_beast_path( :id => beast.id )
else
link_to "kill!", kill_beast_path( :id => beast.id )
end
end
What I've done is separate out the rendering of the beast into a partial which uses collection semantics.
Then I've moved the logic for showing the kill/bury links into a beast helper. This way if you decide to add another action (for example, 'bring back from dead'), you'll only have to change your helper.
Does this help?
A third choice is to use a view model from the Cells gem. This is a very popular framework that brings object-orientation to the view layer in Rails.
# app/cells/beast/cell.rb
class Beast::Cell < Cell::Concept
def show
return dead if model.dead?
kill
end
private
def dead
link_to "bury", bury_beast_path( :id => model.id )
# you could render a view here, too!
end
def kill
link_to "kill!", kill_beast_path( :id => model.id )
end
end
You then render a view model using a helper (in the view or controller).
# app/views/beasts/index.erb
<%= concept(:beast, #beast).call %>
<%-# this returns the link content %>
That's all! You can test this cell isolated in a separate test. Cells also give you view rendering, view inheritance and many more things.
As an example, you could use a view for the kill link.
# app/cells/beast/cell.rb
class Beast::Cell < Cell::Concept
# ..
def kill
render :kill
end
end
This renders the cell's killer view.
# app/cells/beast/views/index.erb
<%= link_to "kill!", kill_beast_path( :id => model.id ) %>
Note the location of the view, it's nicely packaged into the cell directory.
And, yes, cells can do HAML and any other template engine supported by AbstractController.
Another startegy would be to not use templates and helpers at all.
For rendering you could :
render your views directly from your controllers using render(:inline => ). If you still want to keep Views and Controllers formally separated you can create modules / mixins that you include into the controllers.
or create your own view classes and use them to render your response.
The idea behind this is that helpers and rails erb templating system don't take advantage of OOP, so that at the end of the day you can't define general behaviours that you'll specialize according to each controller's/request's needs; more often than not one ends up rewriting very similar looking chunks of code, which is not very nice from a maintenance standpoint.
Then if you still need some helper methods (eg. form_tag, h, raw, ...) you only have to include them in your controller / dedicated view class.
See this : rails-misapprehensions-helpers-are-shit for a fun but useful article.
EDIT: to not sound like a complete douche, I'd say implementing this depends on how big your application is supposed to be, and how often you're going to have to update your code. Plus, if you're delegating the design to a non-programmer, he/she may well be in for some programming courses before digging into your code, which admittedly would be less directly understandable than with templates syntax.
I'm using fragment caching a lot and it is essential to me for good performance. However, due to the complexity of the caching I'm using, I need to offer my testers, a way to disable/enable caching as a session variable. (On a user basis only)
I was thinking about implementing a cache_disabled? method, and I now check for it's value everywhere I use cache. Now, I'm stuck with the following piece of caching, and I can't figure out how to nicely integrate this check :
<% cache(#cache_key_for_consultContent) do %>
<div id="consult">
<%= render :partial => 'LOTS_OF_CONTENT' %>
</div>
<% end %>
I need the content to be called when caching is disabled or content isn't cached yet.
thanks for your creativity! (Please keep it DRY)
In your application helper you could try:
def optional_cache(key, &block)
cache(key, &block) unless session[:disable_caching]
end
Then replace your calls to cache() with optional_cache().