mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
Fix broken and duplicate headings
This commit is contained in:
parent
05b4d59a8d
commit
fd56c3a72e
5 changed files with 7 additions and 7 deletions
|
@ -899,7 +899,7 @@ If you submit the form with empty fields, the result will be similar to the one
|
|||
|
||||
![Error messages](images/error_messages.png)
|
||||
|
||||
NOTE: The appearance of the generated HTML will be different from the one shown, unless you have used scaffolding. See [Customizing the Error Messages CSS](#customizing-error-messages-css).
|
||||
NOTE: The appearance of the generated HTML will be different from the one shown, unless you have used scaffolding. See [Customizing the Error Messages CSS](#customizing-the-error-messages-css).
|
||||
|
||||
You can also use the `error_messages_for` helper to display the error messages of a model assigned to a view template. It is very similar to the previous example and will achieve exactly the same result.
|
||||
|
||||
|
|
|
@ -1022,7 +1022,7 @@ The `:source_type` option specifies the source association type for a `has_one :
|
|||
|
||||
##### `:through`
|
||||
|
||||
The `:through` option specifies a join model through which to perform the query. `has_one :through` associations were discussed in detail <a href="#the-has_one-through-association">earlier in this guide</a>.
|
||||
The `:through` option specifies a join model through which to perform the query. `has_one :through` associations were discussed in detail <a href="#the-has-one-through-association">earlier in this guide</a>.
|
||||
|
||||
##### `:validate`
|
||||
|
||||
|
@ -1367,7 +1367,7 @@ The `:source_type` option specifies the source association type for a `has_many
|
|||
|
||||
##### `:through`
|
||||
|
||||
The `:through` option specifies a join model through which to perform the query. `has_many :through` associations provide a way to implement many-to-many relationships, as discussed <a href="#the-has_many-through-association">earlier in this guide</a>.
|
||||
The `:through` option specifies a join model through which to perform the query. `has_many :through` associations provide a way to implement many-to-many relationships, as discussed <a href="#the-has-many-through-association">earlier in this guide</a>.
|
||||
|
||||
##### `:validate`
|
||||
|
||||
|
|
|
@ -56,7 +56,7 @@ Rails will set you up with what seems like a huge amount of stuff for such a tin
|
|||
|
||||
The `rails server` command launches a small web server named WEBrick which comes bundled with Ruby. You'll use this any time you want to access your application through a web browser.
|
||||
|
||||
INFO: WEBrick isn't your only option for serving Rails. We'll get to that [later](#different-servers).
|
||||
INFO: WEBrick isn't your only option for serving Rails. We'll get to that [later](#server-with-different-backends).
|
||||
|
||||
With no further work, `rails server` will run our new shiny Rails app:
|
||||
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
Getting Started with Engines
|
||||
etting Started with Engines
|
||||
============================
|
||||
|
||||
In this guide you will learn about engines and how they can be used to provide additional functionality to their host applications through a clean and very easy-to-use interface. You will learn the following things in this guide:
|
||||
|
@ -191,7 +191,7 @@ Blorgh::Engine.routes.draw do
|
|||
end
|
||||
```
|
||||
|
||||
Note here that the routes are drawn upon the `Blorgh::Engine` object rather than the `YourApp::Application` class. This is so that the engine routes are confined to the engine itself and can be mounted at a specific point as shown in the [test directory](#test-directory section). This is also what causes the engine's routes to be isolated from those routes that are within the application. This is discussed further in the [Routes](#routes) section of this guide.
|
||||
Note here that the routes are drawn upon the `Blorgh::Engine` object rather than the `YourApp::Application` class. This is so that the engine routes are confined to the engine itself and can be mounted at a specific point as shown in the [test directory](#test-directory) section. This is also what causes the engine's routes to be isolated from those routes that are within the application. This is discussed further in the [Routes](#routes) section of this guide.
|
||||
|
||||
Next, the `scaffold_controller` generator is invoked, generating a controller called `Blorgh::PostsController` (at `app/controllers/blorgh/posts_controller.rb`) and its related views at `app/views/blorgh/posts`. This generator also generates a functional test for the controller (`test/functional/blorgh/posts_controller_test.rb`) and a helper (`app/helpers/blorgh/posts_controller.rb`).
|
||||
|
||||
|
|
|
@ -1189,7 +1189,7 @@ You can also specify a second partial to be rendered between instances of the ma
|
|||
|
||||
Rails will render the `_product_ruler` partial (with no data passed in to it) between each pair of `_product` partials.
|
||||
|
||||
#### Partial Layouts
|
||||
#### Collection Partial Layouts
|
||||
|
||||
When rendering collections it is also possible to use the `:layout` option:
|
||||
|
||||
|
|
Loading…
Reference in a new issue