diff options
Diffstat (limited to 'railties/lib')
| -rw-r--r-- | railties/lib/rails/application.rb | 2 | ||||
| -rw-r--r-- | railties/lib/rails/engine.rb | 56 | ||||
| -rw-r--r-- | railties/lib/rails/paths.rb | 18 |
3 files changed, 40 insertions, 36 deletions
diff --git a/railties/lib/rails/application.rb b/railties/lib/rails/application.rb index 559739b2ec..9e2f1a4b7a 100644 --- a/railties/lib/rails/application.rb +++ b/railties/lib/rails/application.rb @@ -11,7 +11,7 @@ module Rails # == Initialization # # Rails::Application is responsible for executing all railties, engines and plugin - # initializers. Besides, it also executed some bootstrap initializers (check + # initializers. It also executes some bootstrap initializers (check # Rails::Application::Bootstrap) and finishing initializers, after all the others # are executed (check Rails::Application::Finisher). # diff --git a/railties/lib/rails/engine.rb b/railties/lib/rails/engine.rb index eb6fcd5dd7..cb897e94d7 100644 --- a/railties/lib/rails/engine.rb +++ b/railties/lib/rails/engine.rb @@ -5,13 +5,14 @@ require 'rbconfig' require 'rails/engine/railties' module Rails - # Rails::Engine allows you to wrap a specific Rails application and share it across - # different applications. Since Rails 3.0, every <tt>Rails::Application</tt> is nothing - # more than an engine, allowing you to share it very easily. + # <tt>Rails::Engine</tt> allows you to wrap a specific Rails application or subset of + # functionality and share it with other applications. Since Rails 3.0, every + # <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 - # (like <tt>rake_tasks</tt> and +generators+) and configuration available in the - # latter can also be used in the former. + # Any <tt>Rails::Engine</tt> is also a <tt>Rails::Railtie</tt>, so the same + # methods (like <tt>rake_tasks</tt> and +generators+) and configuration + # options that are available in railties can also be used in engines. # # == Creating an Engine # @@ -71,12 +72,13 @@ module Rails # # == Paths # - # Since Rails 3.0, both your application and engines do not have hardcoded paths. - # This means that you are not required to place your controllers at <tt>app/controllers</tt>, - # but in any place which you find convenient. + # Since Rails 3.0, applications and engines have more flexible path configuration (as + # opposed to the previous hardcoded path configuration). This means that you are not + # 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>. - # All you would need to do is: + # You can set that as an option: # # class MyEngine < Rails::Engine # paths["app/controllers"] = "lib/controllers" @@ -105,9 +107,9 @@ module Rails # paths["config/routes"] # => ["config/routes.rb"] # end # - # Your <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. - # So if you have <tt>app/observers</tt>, it's added by default. + # 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. + # If you have an <tt>app/observers</tt> folder for example, it will be added by default. # # == Endpoint # @@ -130,8 +132,8 @@ module Rails # # == Middleware stack # - # As an engine can now be rack endpoint, it can also have a middleware stack. The usage is exactly - # the same as in <tt>Application</tt>: + # As an engine can now be a rack endpoint, it can also have a middleware + # stack. The usage is exactly the same as in <tt>Application</tt>: # # module MyEngine # class Engine < Rails::Engine @@ -141,8 +143,8 @@ module Rails # # == Routes # - # If you don't specify an endpoint, routes will be used as the default endpoint. You can use them - # just like you use an application's routes: + # If you don't specify an endpoint, routes will be used as the default + # endpoint. You can use them just like you use an application's routes: # # # ENGINE/config/routes.rb # MyEngine::Engine.routes.draw do @@ -174,6 +176,7 @@ module Rails # == Engine name # # There are some places where an Engine's name is used: + # # * routes: when you mount an Engine with <tt>mount(MyEngine::Engine => '/my_engine')</tt>, # it's used as default :as option # * some of the rake tasks are based on engine name, e.g. <tt>my_engine:install:migrations</tt>, @@ -191,8 +194,8 @@ module Rails # == Isolated Engine # # 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 - # will be available to your engine's controllers. + # as if they were created inside the application itself. This means that all helpers and + # 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 # has its own router. To do that, you simply need to call +isolate_namespace+. This method requires @@ -240,9 +243,9 @@ module Rails # text_field :title # => <input type="text" name="article[title]" id="article_title" /> # 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 - # 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 # @@ -274,12 +277,13 @@ module Rails # 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. # - # Finally, if you want to generate a url to an engine's route using <tt>polymorphic_url</tt>, you also need - # to pass the engine helper. Let's 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 + # Finally, if you want to generate a url to an engine's route using + # <tt>polymorphic_url</tt>, you also need to pass the engine helper. Let's + # 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: # # form_for([my_engine, @user]) @@ -319,7 +323,7 @@ module Rails # # 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 - # 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 # the <tt>seeds.rb</tt> file. You can load that data using the <tt>load_seed</tt> method, e.g. diff --git a/railties/lib/rails/paths.rb b/railties/lib/rails/paths.rb index 3f1d2ca87d..de3d0b6fc5 100644 --- a/railties/lib/rails/paths.rb +++ b/railties/lib/rails/paths.rb @@ -2,7 +2,7 @@ require 'set' module Rails module Paths - # This object is an extended hash that behaves as root of the Rails::Paths system. + # This object is an extended hash that behaves as root of the <tt>Rails::Paths</tt> system. # It allows you to collect information about how you want to structure your application # paths by a Hash like API. It requires you to give a physical path on initialization. # @@ -10,13 +10,13 @@ module Rails # root.add "app/controllers", :eager_load => true # # The command above creates a new root object and add "app/controllers" as a path. - # This means we can get a Path object back like below: + # This means we can get a +Rails::Paths::Path+ object back like below: # # path = root["app/controllers"] # path.eager_load? # => true # path.is_a?(Rails::Paths::Path) # => true # - # The Path object is simply an array and allows you to easily add extra paths: + # The +Path+ object is simply an array and allows you to easily add extra paths: # # path.is_a?(Array) # => true # path.inspect # => ["app/controllers"] @@ -24,17 +24,17 @@ module Rails # path << "lib/controllers" # path.inspect # => ["app/controllers", "lib/controllers"] # - # Notice that when you add a path using #add, the path object created already - # contains the path with the same path value given to #add. In some situations, + # Notice that when you add a path using +add+, the path object created already + # contains the path with the same path value given to +add+. In some situations, # you may not want this behavior, so you can give :with as option. # # root.add "config/routes", :with => "config/routes.rb" # root["config/routes"].inspect # => ["config/routes.rb"] # - # #add also accepts the following options as argument: eager_load, autoload, - # autoload_once and glob. + # The +add+ method accepts the following options as arguments: + # eager_load, autoload, autoload_once and glob. # - # Finally, the Path object also provides a few helpers: + # Finally, the +Path+ object also provides a few helpers: # # root = Root.new "/rails" # root.add "app/controllers" @@ -42,7 +42,7 @@ module Rails # root["app/controllers"].expanded # => ["/rails/app/controllers"] # root["app/controllers"].existent # => ["/rails/app/controllers"] # - # Check the Path documentation for more information. + # Check the <tt>Rails::Paths::Path</tt> documentation for more information. class Root < ::Hash attr_accessor :path |