If you don't put a yield in your layout, the layout itself will render just fine, but any additional content coded into the action templates will not be correctly placed within the layout. Now when you hit up the static about route in your browser, you will see Welcome To The Flatiron Store! This means that, when the layout rendered, it pulled the action's specific template into the correct place —— right where we added the yield statement!
Those of you who remember Ruby blocks might be thinking that this looks very similar to how Ruby yields to blocks in a method call.
The same principle is at work here: we're yielding to a chunk of code and don't know what it will do in advance. We always want to run the layout part of the method, and we let any other chunk of code that produces HTML a template in this case run at the yield point in the method call.
At its simplest level, this is what happens when a request is made to your Rails application:. So this means that, for every request handled by Rails, at most one layout and action template will be used.
The action template can call out to other templates, called partials, to render itself. Partials are covered in upcoming lessons, so don't worry too much about the concept for now. Think about the example from earlier in this lesson, the Flatiron store app. As mentioned before, it would make sense to have the same layout for the product list, product detail pages, and cart because you would want some common elements in the same place within each view.
But when you add administrative functionality to the online store —— say, in order to allow someone to add new products to the site, update prices, and perhaps draw reports —— you'll probably want to use a different layout, which is quite easy to do with Rails. Rails uses a simple convention to find the correct layout for your request. With the exception of the admin section of a site, most applications use the default layout for everything, so there's no need to have a layout for each controller.
You want to have a consistent look and feel throughout your site, using a different layout only if the situation really warrants it. If you need to override the conventions explained above, you can easily do so. If you want to render your action template without a layout, you can do the following:. Note: It's pretty unusual to not render the layout in a standard action. Rails Layouts And Templates This lesson will show you how to use layouts to achieve a common look and feel between different views in your app.
Objectives After this lesson, you'll be able to Identify the default application layout. Yield to view templates from a layout. You would probably have a few different views in this app, for example: A list of products A detail view that shows more info for a selected product A shopping cart Across all these views you would want a consistent look. Layouts to the Rescue Luckily, you don't need to copy content from one template file to the next because layouts in Rails are enabled by default.
How Layouts and Templates are Stitched Together At its simplest level, this is what happens when a request is made to your Rails application: Rails finds the template for the corresponding action based either on convention or any other options passed to the render method in your controller action.
Rails uses the action template to generate the content specific to the action. Note that the template might be composed of partial views, which you'll learn about a bit later. It then looks for the layout's yield statement and inserts the action's template there. Deciding on a Layout Through Convention Rails uses a simple convention to find the correct layout for your request.
Overriding Conventions If you need to override the conventions explained above, you can easily do so. Recap Use layouts to provide a common look and feel between different views of your app. Next, we'll take what we've learned here and apply it in a lab. Unlock your future in tech. Learn to code. Start Coding Bootcamp Prep. Related Topics.
Learn about Flatiron School's Mission. Author Site Comments Erik Nomitch prelang. Rails 4. Rails 3. These Rails 2. A fork of the RailsWizard gem; actively maintained. Ask Question. Asked 8 years, 11 months ago. Active 1 year, 6 months ago. Viewed 7k times. Improve this question. Add a comment. Active Oldest Votes.
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.
It's about information and state, not necessarily about 'looking good'. You hire us. We give you coolness. You pay us. Improve this answer. Prakash Murthy Prakash Murthy So layouts are specific types of templates? Yup, layouts are specific types of templates. There can be multiple layout files; which layout is rendered is dependent on the config in the controllers.
Other layouts can be explicitly invoked from the controllers. Partials are like subroutines in programs, where the details of a specific functionality is hidden away from the main program. Partials help in keeping the views DRY.
0コメント