mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
misc grammar and clarity changes for rails/engine docs
This commit is contained in:
parent
eb716f6307
commit
2f30fb03bb
1 changed files with 29 additions and 26 deletions
|
@ -5,13 +5,14 @@ require 'rbconfig'
|
||||||
require 'rails/engine/railties'
|
require 'rails/engine/railties'
|
||||||
|
|
||||||
module Rails
|
module Rails
|
||||||
# Rails::Engine allows you to wrap a specific Rails application and share it across
|
# Rails::Engine allows you to wrap a specific Rails application or subset of
|
||||||
# different applications. Since Rails 3.0, every <tt>Rails::Application</tt> is nothing
|
# functionality and share it with other applications. Since Rails 3.0, every
|
||||||
# more than an engine, allowing you to share it very easily.
|
# <tt>Rails::Application</tt> is just an engine, which allows for simple
|
||||||
|
# feature and application sharing.
|
||||||
#
|
#
|
||||||
# Any <tt>Rails::Engine</tt> is also a <tt>Rails::Railtie</tt>, so the same methods
|
# Any <tt>Rails::Engine</tt> is also a <tt>Rails::Railtie</tt>, so the same
|
||||||
# (like <tt>rake_tasks</tt> and +generators+) and configuration available in the
|
# methods (like <tt>rake_tasks</tt> and +generators+) and configuration
|
||||||
# latter can also be used in the former.
|
# options that are available in railties can also be used in engines.
|
||||||
#
|
#
|
||||||
# == Creating an Engine
|
# == Creating an Engine
|
||||||
#
|
#
|
||||||
|
@ -71,12 +72,13 @@ module Rails
|
||||||
#
|
#
|
||||||
# == Paths
|
# == Paths
|
||||||
#
|
#
|
||||||
# Since Rails 3.0, both your application and engines do not have hardcoded paths.
|
# Since Rails 3.0, applications and engines have more flexible path configuration (as
|
||||||
# This means that you are not required to place your controllers at <tt>app/controllers</tt>,
|
# opposed to the previous hardcoded path configuration). This means that you are not
|
||||||
# but in any place which you find convenient.
|
# required to place your controllers at <tt>app/controllers</tt>, but in any place
|
||||||
|
# which you find convenient.
|
||||||
#
|
#
|
||||||
# For example, let's suppose you want to place your controllers in <tt>lib/controllers</tt>.
|
# For example, let's suppose you want to place your controllers in <tt>lib/controllers</tt>.
|
||||||
# All you would need to do is:
|
# You can set that as an option:
|
||||||
#
|
#
|
||||||
# class MyEngine < Rails::Engine
|
# class MyEngine < Rails::Engine
|
||||||
# paths["app/controllers"] = "lib/controllers"
|
# paths["app/controllers"] = "lib/controllers"
|
||||||
|
@ -105,9 +107,9 @@ module Rails
|
||||||
# paths["config/routes"] # => ["config/routes.rb"]
|
# paths["config/routes"] # => ["config/routes.rb"]
|
||||||
# end
|
# end
|
||||||
#
|
#
|
||||||
# Your <tt>Application</tt> class adds a couple more paths to this set. And as in your
|
# The <tt>Application</tt> class adds a couple more paths to this set. And as in your
|
||||||
# <tt>Application</tt>,all folders under +app+ are automatically added to the load path.
|
# <tt>Application</tt>, all folders under +app+ are automatically added to the load path.
|
||||||
# So if you have <tt>app/observers</tt>, it's added by default.
|
# If you have an <tt>app/observers</tt> folder for example, it will be added by default.
|
||||||
#
|
#
|
||||||
# == Endpoint
|
# == Endpoint
|
||||||
#
|
#
|
||||||
|
@ -130,8 +132,8 @@ module Rails
|
||||||
#
|
#
|
||||||
# == Middleware stack
|
# == Middleware stack
|
||||||
#
|
#
|
||||||
# As an engine can now be rack endpoint, it can also have a middleware stack. The usage is exactly
|
# As an engine can now be a rack endpoint, it can also have a middleware
|
||||||
# the same as in <tt>Application</tt>:
|
# stack. The usage is exactly the same as in <tt>Application</tt>:
|
||||||
#
|
#
|
||||||
# module MyEngine
|
# module MyEngine
|
||||||
# class Engine < Rails::Engine
|
# class Engine < Rails::Engine
|
||||||
|
@ -141,8 +143,8 @@ module Rails
|
||||||
#
|
#
|
||||||
# == Routes
|
# == Routes
|
||||||
#
|
#
|
||||||
# If you don't specify an endpoint, routes will be used as the default endpoint. You can use them
|
# If you don't specify an endpoint, routes will be used as the default
|
||||||
# just like you use an application's routes:
|
# endpoint. You can use them just like you use an application's routes:
|
||||||
#
|
#
|
||||||
# # ENGINE/config/routes.rb
|
# # ENGINE/config/routes.rb
|
||||||
# MyEngine::Engine.routes.draw do
|
# MyEngine::Engine.routes.draw do
|
||||||
|
@ -191,8 +193,8 @@ module Rails
|
||||||
# == Isolated Engine
|
# == Isolated Engine
|
||||||
#
|
#
|
||||||
# Normally when you create controllers, helpers and models inside an engine, they are treated
|
# Normally when you create controllers, helpers and models inside an engine, they are treated
|
||||||
# as they were created inside the application. This means all application helpers and named routes
|
# as if they were created inside the application itself. This means that all helpers and
|
||||||
# will be available to your engine's controllers.
|
# named routes from the application will be available to your engine's controllers as well.
|
||||||
#
|
#
|
||||||
# However, sometimes you want to isolate your engine from the application, especially if your engine
|
# However, sometimes you want to isolate your engine from the application, especially if your engine
|
||||||
# has its own router. To do that, you simply need to call +isolate_namespace+. This method requires
|
# has its own router. To do that, you simply need to call +isolate_namespace+. This method requires
|
||||||
|
@ -240,9 +242,9 @@ module Rails
|
||||||
# text_field :title # => <input type="text" name="article[title]" id="article_title" />
|
# text_field :title # => <input type="text" name="article[title]" id="article_title" />
|
||||||
# end
|
# end
|
||||||
#
|
#
|
||||||
# Additionally an isolated engine will set its name according to namespace, so
|
# Additionally, an isolated engine will set its name according to namespace, so
|
||||||
# MyEngine::Engine.engine_name will be "my_engine". It will also set MyEngine.table_name_prefix
|
# MyEngine::Engine.engine_name will be "my_engine". It will also set MyEngine.table_name_prefix
|
||||||
# to "my_engine_", changing MyEngine::Article model to use my_engine_article table.
|
# to "my_engine_", changing the MyEngine::Article model to use the my_engine_article table.
|
||||||
#
|
#
|
||||||
# == Using Engine's routes outside Engine
|
# == Using Engine's routes outside Engine
|
||||||
#
|
#
|
||||||
|
@ -274,12 +276,13 @@ module Rails
|
||||||
# end
|
# end
|
||||||
# end
|
# end
|
||||||
#
|
#
|
||||||
# Note that the <tt>:as</tt> option given to mount takes the <tt>engine_name</tT> as default, so most of the time
|
# Note that the <tt>:as</tt> option given to mount takes the <tt>engine_name</tt> as default, so most of the time
|
||||||
# you can simply omit it.
|
# you can simply omit it.
|
||||||
#
|
#
|
||||||
# Finally, if you want to generate a url to an engine's route using <tt>polymorphic_url</tt>, you also need
|
# Finally, if you want to generate a url to an engine's route using
|
||||||
# to pass the engine helper. Let's say that you want to create a form pointing to one of the
|
# <tt>polymorphic_url</tt>, you also need to pass the engine helper. Let's
|
||||||
# engine's routes. All you need to do is pass the helper as the first element in array with
|
# say that you want to create a form pointing to one of the engine's routes.
|
||||||
|
# All you need to do is pass the helper as the first element in array with
|
||||||
# attributes for url:
|
# attributes for url:
|
||||||
#
|
#
|
||||||
# form_for([my_engine, @user])
|
# form_for([my_engine, @user])
|
||||||
|
@ -319,7 +322,7 @@ module Rails
|
||||||
#
|
#
|
||||||
# Note that some of the migrations may be skipped if a migration with the same name already exists
|
# Note that some of the migrations may be skipped if a migration with the same name already exists
|
||||||
# in application. In such a situation you must decide whether to leave that migration or rename the
|
# in application. In such a situation you must decide whether to leave that migration or rename the
|
||||||
# migration in application and rerun copying migrations.
|
# migration in the application and rerun copying migrations.
|
||||||
#
|
#
|
||||||
# If your engine has migrations, you may also want to prepare data for the database in
|
# If your engine has migrations, you may also want to prepare data for the database in
|
||||||
# the <tt>seeds.rb</tt> file. You can load that data using the <tt>load_seed</tt> method, e.g.
|
# the <tt>seeds.rb</tt> file. You can load that data using the <tt>load_seed</tt> method, e.g.
|
||||||
|
|
Loading…
Reference in a new issue