@@ -186,7 +186,8 @@ The full set of methods that can be used in this block are as follows:
*`javascript_engine` configures the engine to be used (for eg. coffee) when generating assets. Defaults to `:js`.
*`orm` defines which orm to use. Defaults to `false` and will use Active Record by default.
*`resource_controller` defines which generator to use for generating a controller when using `rails generate resource`. Defaults to `:controller`.
*`resource_route` defines whether inject resource route definition in routes or not. Defaults to `true`.
*`resource_route` defines whether a resource route definition should be generated
or not. Defaults to `true`.
*`scaffold_controller` different from `resource_controller`, defines which generator to use for generating a _scaffolded_ controller when using `rails generate scaffold`. Defaults to `:scaffold_controller`.
*`stylesheets` turns on the hook for stylesheets in generators. Used in Rails for when the `scaffold` generator is run, but this hook can be used in other generates as well. Defaults to `true`.
*`stylesheet_engine` configures the stylesheet engine (for eg. sass) to be used when generating assets. Defaults to `:css`.
@@ -500,7 +500,10 @@ You can make use of this feature, e.g. when working with a large amount of stati
### Organization of Locale Files
When you are using the default SimpleStore shipped with the i18n library, dictionaries are stored in plain-text files on the disc. Putting translations for all parts of your application in one file per locale could be hard to manage. You can store these files in a hierarchy which makes sense to you.
When you are using the default SimpleStore shipped with the i18n library,
dictionaries are stored in plain-text files on the disk. Putting translations
for all parts of your application in one file per locale could be hard to
manage. You can store these files in a hierarchy which makes sense to you.
For example, your `config/locales` directory could look like this:
@@ -809,13 +809,16 @@ As long as `Sprockets` responds to `call` and returns a `[status, headers, body]
NOTE: For the curious, `'articles#index'` actually expands out to `ArticlesController.action(:index)`, which returns a valid Rack application.
If you specify a rack application as the endpoint for a matcher remember that the route will be unchanged in the receiving application. With the following route your rack application should expect the route to be '/admin':
If you specify a Rack application as the endpoint for a matcher, remember that
the route will be unchanged in the receiving application. With the following
route your Rack application should expect the route to be '/admin':
```ruby
match'/admin',to: AdminApp,via: :all
```
If you would prefer to have your rack application receive requests at the root path instead use mount:
If you would prefer to have your Rack application receive requests at the root