1
0
Fork 0
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:
Matt Jankowski 2011-07-12 09:54:43 -04:00
parent eb716f6307
commit 2f30fb03bb

View file

@ -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.