From b9b4cfcebc3f77e2cf828450ccb9ac1b2f867a67 Mon Sep 17 00:00:00 2001 From: Dan McDonald Date: Sun, 9 Oct 2011 09:31:11 -0600 Subject: [PATCH 01/15] ActiveRecordStore is now called SessionStore. --- railties/guides/source/security.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/railties/guides/source/security.textile b/railties/guides/source/security.textile index 73c7a80ff6..0f100e0adf 100644 --- a/railties/guides/source/security.textile +++ b/railties/guides/source/security.textile @@ -82,9 +82,9 @@ This will also be a good idea, if you modify the structure of an object and old h4. Session Storage --- _Rails provides several storage mechanisms for the session hashes. The most important are ActiveRecordStore and CookieStore._ +-- _Rails provides several storage mechanisms for the session hashes. The most important are SessionStore and CookieStore._ -There are a number of session storages, i.e. where Rails saves the session hash and session id. Most real-live applications choose ActiveRecordStore (or one of its derivatives) over file storage due to performance and maintenance reasons. ActiveRecordStore keeps the session id and hash in a database table and saves and retrieves the hash on every request. +There are a number of session storages, i.e. where Rails saves the session hash and session id. Most real-live applications choose SessionStore (or one of its derivatives) over file storage due to performance and maintenance reasons. SessionStore keeps the session id and hash in a database table and saves and retrieves the hash on every request. Rails 2 introduced a new default session storage, CookieStore. CookieStore saves the session hash directly in a cookie on the client-side. The server retrieves the session hash from the cookie and eliminates the need for a session id. That will greatly increase the speed of the application, but it is a controversial storage option and you have to think about the security implications of it: From 74b9441c0df39bba58b453701b2f3add72fc7ebe Mon Sep 17 00:00:00 2001 From: mhutchin Date: Sun, 9 Oct 2011 09:36:19 -0700 Subject: [PATCH 02/15] Copy editing: s/Rails guesses/Rails assumes/g --- railties/guides/source/association_basics.textile | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/railties/guides/source/association_basics.textile b/railties/guides/source/association_basics.textile index 8943bfa0a3..5f8997e7be 100644 --- a/railties/guides/source/association_basics.textile +++ b/railties/guides/source/association_basics.textile @@ -671,7 +671,7 @@ WARNING: You should not specify this option on a +belongs_to+ association that i h6(#belongs_to-foreign_key). +:foreign_key+ -By convention, Rails guesses that the column used to hold the foreign key on this model is the name of the association with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: +By convention, Rails assumes that the column used to hold the foreign key on this model is the name of the association with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: class Order < ActiveRecord::Base @@ -902,7 +902,7 @@ If you set the +:dependent+ option to +:destroy+, then deleting this object will h6(#has_one-foreign_key). +:foreign_key+ -By convention, Rails guesses that the column used to hold the foreign key on the other model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: +By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: class Supplier < ActiveRecord::Base @@ -954,7 +954,7 @@ The +:order+ option dictates the order in which associated objects will be recei h6(#has_one-primary_key). +:primary_key+ -By convention, Rails guesses that the column used to hold the primary key of this model is +id+. You can override this and explicitly specify the primary key with the +:primary_key+ option. +By convention, Rails assumes that the column used to hold the primary key of this model is +id+. You can override this and explicitly specify the primary key with the +:primary_key+ option. h6(#has_one-readonly). +:readonly+ @@ -1262,7 +1262,7 @@ Normally Rails automatically generates the proper SQL to fetch the association m h6(#has_many-foreign_key). +:foreign_key+ -By convention, Rails guesses that the column used to hold the foreign key on the other model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: +By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: class Customer < ActiveRecord::Base @@ -1345,7 +1345,7 @@ end h6(#has_many-primary_key). +:primary_key+ -By convention, Rails guesses that the column used to hold the primary key of the association is +id+. You can override this and explicitly specify the primary key with the +:primary_key+ option. +By convention, Rails assumes that the column used to hold the primary key of the association is +id+. You can override this and explicitly specify the primary key with the +:primary_key+ option. h6(#has_many-readonly). +:readonly+ @@ -1619,7 +1619,7 @@ The +has_and_belongs_to_many+ association supports these options: h6(#has_and_belongs_to_many-association_foreign_key). +:association_foreign_key+ -By convention, Rails guesses that the column in the join table used to hold the foreign key pointing to the other model is the name of that model with the suffix +_id+ added. The +:association_foreign_key+ option lets you set the name of the foreign key directly: +By convention, Rails assumes that the column in the join table used to hold the foreign key pointing to the other model is the name of that model with the suffix +_id+ added. The +:association_foreign_key+ option lets you set the name of the foreign key directly: TIP: The +:foreign_key+ and +:association_foreign_key+ options are useful when setting up a many-to-many self-join. For example: @@ -1687,7 +1687,7 @@ Normally Rails automatically generates the proper SQL to fetch the association m h6(#has_and_belongs_to_many-foreign_key). +:foreign_key+ -By convention, Rails guesses that the column in the join table used to hold the foreign key pointing to this model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: +By convention, Rails assumes that the column in the join table used to hold the foreign key pointing to this model is the name of this model with the suffix +_id+ added. The +:foreign_key+ option lets you set the name of the foreign key directly: class User < ActiveRecord::Base From 5f632a88a63142a2cd4e734b0ab7486bf34d64bf Mon Sep 17 00:00:00 2001 From: mhutchin Date: Sun, 9 Oct 2011 15:56:01 -0700 Subject: [PATCH 03/15] Minor copy editing --- railties/guides/source/association_basics.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/railties/guides/source/association_basics.textile b/railties/guides/source/association_basics.textile index 5f8997e7be..56f51e6ae7 100644 --- a/railties/guides/source/association_basics.textile +++ b/railties/guides/source/association_basics.textile @@ -1551,7 +1551,7 @@ The collection.find method finds objects within the collection :conditions => ["created_at > ?", 2.days.ago]) -NOTE: Starting Rails 3, supplying options to +ActiveRecord::Base.find+ method is discouraged. Use collection.where instead when you need to pass conditions. +NOTE: Beginning with Rails 3, supplying options to the +ActiveRecord::Base.find+ method is discouraged. Use collection.where instead when you need to pass conditions. h6(#has_and_belongs_to_many-collection-where). collection.where(...) From 11b183eb927d8cd12ce33e43d9f4e2642fb988e7 Mon Sep 17 00:00:00 2001 From: mhutchin Date: Sun, 9 Oct 2011 16:07:30 -0700 Subject: [PATCH 04/15] Copy editing to improve readability, consistency, and tone --- railties/guides/source/association_basics.textile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/railties/guides/source/association_basics.textile b/railties/guides/source/association_basics.textile index 56f51e6ae7..479a3c1e30 100644 --- a/railties/guides/source/association_basics.textile +++ b/railties/guides/source/association_basics.textile @@ -576,7 +576,7 @@ The create_association method returns a new object of the asso h5. Options for +belongs_to+ -In many situations, you can use the default behavior of +belongs_to+ without any customization. But despite Rails' emphasis of convention over configuration, you can alter that behavior in a number of ways. This section covers the options that you can pass when you create a +belongs_to+ association. For example, an association with several options might look like this: +While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the +belongs_to+ association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this assocation uses two such options: class Order < ActiveRecord::Base @@ -842,7 +842,7 @@ The create_association method returns a new object of the asso h5. Options for +has_one+ -In many situations, you can use the default behavior of +has_one+ without any customization. But despite Rails' emphasis of convention over configuration, you can alter that behavior in a number of ways. This section covers the options that you can pass when you create a +has_one+ association. For example, an association with several options might look like this: +While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the +has_one+ association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this assocation uses two such options: class Supplier < ActiveRecord::Base @@ -1156,7 +1156,7 @@ The collection.create method returns a new object of the assoc h5. Options for +has_many+ -In many situations, you can use the default behavior for +has_many+ without any customization. But you can alter that behavior in a number of ways. This section covers the options that you can pass when you create a +has_many+ association. For example, an association with several options might look like this: +While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the +has_many+ association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this assocation uses two such options: class Customer < ActiveRecord::Base @@ -1585,7 +1585,7 @@ The collection.create method returns a new object of the assoc h5. Options for +has_and_belongs_to_many+ -In many situations, you can use the default behavior for +has_and_belongs_to_many+ without any customization. But you can alter that behavior in a number of ways. This section covers the options that you can pass when you create a +has_and_belongs_to_many+ association. For example, an association with several options might look like this: +While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the +has_and_belongs_to_many+ association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this assocation uses two such options: class Parts < ActiveRecord::Base From 454492dfd7d364bb4386935bd8d5f636d5163e2b Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Thu, 6 Oct 2011 18:20:38 +1100 Subject: [PATCH 05/15] [engines guide] Credit where credit is due --- railties/guides/source/engines.textile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index ddd2e50a6c..ce041141a0 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -22,6 +22,8 @@ Engines can also be isolated from their host applications. This means that an ap To see demonstrations of other engines, check out "Devise":https://github.com/plataformatec/devise, an engine that provides authentication for its parent applications, or "Forem":https://github.com/radar/forem, an engine that provides forum functionality. +Finally, engines would not have be possible without the work of James Adam, Piotr Sarnacki, the Rails Core Team, and a number of other people. If you ever meet them, don't forget to say thanks! + h3. Generating an engine To generate an engine with Rails 3.1, you will need to run the plugin generator and pass it the +--mountable+ option. To generate the beginnings of the "blorgh" engine you will need to run this command in a terminal: From c580812a5560f002eeefa6ddba8c4e8acc0adf54 Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Thu, 6 Oct 2011 18:28:50 +1100 Subject: [PATCH 06/15] [engines guide] Credit where credit is due + explaning directory structure --- railties/guides/source/engines.textile | 43 ++++++++++++++++++++++++-- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index ce041141a0..6b0c8b3b2f 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -12,7 +12,7 @@ endprologue. h3. What are engines? -Engines can be considered miniature applications that provide functionality to their host applications. A Rails application is actually just a "supercharged" engine, with the +Rails::Application+ class inheriting from +Rails::Engine+. Therefore, engines and applications share common functionality but are at the same time two separate beasts. Engines and applications also share a common structure, as you'll see later in this guide. +Engines can be considered miniature applications that provide functionality to their host applications. A Rails application is actually just a "supercharged" engine, with the +Rails::Application+ class inheriting from +Rails::Engine+. Therefore, engines and applications share common functionality but are at the same time two separate beasts. Engines and applications also share a common structure, as you'll see througout this guide. Engines are also closely related to plugins where the two share a common +lib+ directory structure and are both generated using the +rails plugin new+ generator. @@ -34,7 +34,9 @@ $ rails plugin new blorgh --mountable The +--mountable+ option tells the plugin generator that you want to create an engine (which is a mountable plugin, hence the option name), creating the basic directory structure of an engine by providing things such as the foundations of an +app+ folder, as well a +config/routes.rb+ file. This generator also provides a file at +lib/blorgh/engine.rb+ which is identical in function to an application's +config/application.rb+ file. -Inside the +app+ directory there lives the standard +assets+, +controllers+, +helpers+, +mailers+, +models+ and +views+ directories that you should be familiar with from an application. +h4. Inside an engine + +h5. Critical files At the root of the engine's directory, lives a +blorgh.gemspec+ file. When you include the engine into the application later on, you will do so with this line in a Rails application's +Gemfile+: @@ -54,11 +56,46 @@ end Within +lib/blorgh/engine.rb+ is the base class for the engine: - TODO: lib/blorgh/engine.rb +module Blorgh + class Engine < Rails::Engine + isolate_namespace Blorgh + end +end +By inheriting from the +Rails::Engine+ class, this engine gains all the functionality it needs, such as being able to serve requests to its controllers. + +The +isolate_namespace+ method here deserves special notice. This call is responsible for isolating the controllers, models, routes and other things into their own namespace. Without this, there is a possibility that the engine's components could "leak" into the application, causing unwanted disruption. It is recommended that this line be left within this file. + +h5. +app+ directory + +Inside the +app+ directory there lives the standard +assets+, +controllers+, +helpers+, +mailers+, +models+ and +views+ directories that you should be familiar with from an application. The +helpers+, +mailers+ and +models+ directories are empty and so aren't described in this section. We'll look more into models in a future section. + +Within the +app/assets+ directory, there is the +images+, +javascripts+ and +stylesheets+ directories which, again, you should be familiar with due to their similarities of an application. One difference here however is that each directory contains a sub-directory with the engine name. Because this engine is going to be namespaced, its assets should be too. + Within the +app/controllers+ directory there is a +blorgh+ directory and inside that a file called +application_controller.rb+. This file will provide any common functionality for the controllers of the engine. The +blorgh+ directory is where the other controllers for the engine will go. By placing them within this namespaced directory, you prevent them from possibly clashing with identically-named controllers within other engines or even within the application. +Lastly, the +app/views+ directory contains a +layouts+ folder which contains file at +blorgh/application.html.erb+ which allows you to specify a layout for the engine. If this engine is to be used as a stand-alone engine, then we would add any customization to its layout in this file, rather than the applications +app/views/layouts/application.html.erb+ file. + +h5. +script+ directory + +This directory contains one file, +script/rails+, which allows you to use the +rails+ sub-commands and generators just like you would within an application. This means that you will very easily be able to generate new controllers and models for this engine. + +h5. +test+ directory + +The +test+ directory is where tests for the engine will go. To test the engine, there is a cut-down version of a Rails application embedded within it at +test/dummy+. This application will mount the engine in the +test/dummy/config/routes.rb+ file: + + +Rails.application.routes.draw do + + mount Blorgh::Engine => "/blorgh" +end + + +This line mounts the engine at the path of +/blorgh+, which will make it accessible through the application only at that path. We will look more into mounting an engine after we have developed some features. + +Also in the test directory is the +test/integration+ directory, where integration tests for the engine should be placed. + h3. Providing engine functionality TODO: Brief explanation of what this engine is going to be doing and what we will have once we are done. From 685c24d730edb3e3c5f3b750e510863c1d9aff95 Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Fri, 7 Oct 2011 07:15:14 +1100 Subject: [PATCH 07/15] [engines guide] reword first two dot points in prologue --- railties/guides/source/engines.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index 6b0c8b3b2f..17c48319ac 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -2,8 +2,8 @@ h2. Getting 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: -* What are engines -* Generating an engine +* What makes an engine +* How to generate an engine * Building features for the engine * Hooking the engine into an application * Overriding engine functionality in the application From b02bd74c13ba09217bb45b5fa228ddd9592a2600 Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Fri, 7 Oct 2011 09:06:43 +1100 Subject: [PATCH 08/15] [engines guide] begin explaining what the scaffold generator outputs within an engine --- railties/guides/source/engines.textile | 58 +++++++++++++++++++++++++- 1 file changed, 56 insertions(+), 2 deletions(-) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index 17c48319ac..7b1c0a59e2 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -75,7 +75,7 @@ Within the +app/assets+ directory, there is the +images+, +javascripts+ and +sty Within the +app/controllers+ directory there is a +blorgh+ directory and inside that a file called +application_controller.rb+. This file will provide any common functionality for the controllers of the engine. The +blorgh+ directory is where the other controllers for the engine will go. By placing them within this namespaced directory, you prevent them from possibly clashing with identically-named controllers within other engines or even within the application. -Lastly, the +app/views+ directory contains a +layouts+ folder which contains file at +blorgh/application.html.erb+ which allows you to specify a layout for the engine. If this engine is to be used as a stand-alone engine, then we would add any customization to its layout in this file, rather than the applications +app/views/layouts/application.html.erb+ file. +Lastly, the +app/views+ directory contains a +layouts+ folder which contains file at +blorgh/application.html.erb+ which allows you to specify a layout for the engine. If this engine is to be used as a stand-alone engine, then you would add any customization to its layout in this file, rather than the applications +app/views/layouts/application.html.erb+ file. h5. +script+ directory @@ -92,12 +92,66 @@ Rails.application.routes.draw do end -This line mounts the engine at the path of +/blorgh+, which will make it accessible through the application only at that path. We will look more into mounting an engine after we have developed some features. +This line mounts the engine at the path of +/blorgh+, which will make it accessible through the application only at that path. We will look more into mounting an engine after some features have been developed. Also in the test directory is the +test/integration+ directory, where integration tests for the engine should be placed. h3. Providing engine functionality +The engine that this guide covers will provide posting and commenting functionality. + +h4. Generating a post resource + +The first thing to generate for a blog engine is the +Post+ model and related controller. To quickly generate this, you can use the Rails scaffold generator. + + +$ rails generate scaffold post title:string text:text +invoke active_record +create db/migrate/20111006201642_create_blorgh_posts.rb +create app/models/blorgh/post.rb +invoke test_unit +create test/unit/blorgh/post_test.rb +create test/fixtures/blorgh/posts.yml + route resources :posts +invoke scaffold_controller +create app/controllers/blorgh/posts_controller.rb +invoke erb +create app/views/blorgh/posts +create app/views/blorgh/posts/index.html.erb +create app/views/blorgh/posts/edit.html.erb +create app/views/blorgh/posts/show.html.erb +create app/views/blorgh/posts/new.html.erb +create app/views/blorgh/posts/_form.html.erb +invoke test_unit +create test/functional/blorgh/posts_controller_test.rb +invoke helper +create app/helpers/blorgh/posts_helper.rb +invoke test_unit +create test/unit/helpers/blorgh/posts_helper_test.rb +invoke assets +invoke js +create app/assets/javascripts/blorgh/posts.js +invoke css +create app/assets/stylesheets/blorgh/posts.css +invoke css +create app/assets/stylesheets/scaffold.css + + +The first thing that the scaffold generator does is invoke the +active_record+ generator, which generates a migration and a model for the resource. Note here, however, that the migration is called +create_blorgh_posts+ rather than the usual +create_posts+. This is due to the +isolate_namespace+ method called in the +Blorgh::Engine+ class's definition. The model here is also namespaced, being placed at +app/models/blorgh/post.rb+ rather than +app/models/post.rb+. + +Next, the +test_unit+ generator is invoked for this model, generating a unit test at +test/unit/blorgh/post_test.rb+ (rather than +test/unit/post_test.rb+) and a fixture at +test/fixtures/blorgh/posts.yml+ (rather than +test/fixtures/posts.yml+). + +After that, a line for the resource is inserted into the +config/routes.rb+ file for the engine. This line is simply +resources :posts+, turning the +config/routes.rb+ file into this: + + +Blorgh::Engine.routes.draw do + resources :posts + +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. + TODO: Brief explanation of what this engine is going to be doing and what we will have once we are done. TODO: Generate a posts scaffold (maybe?) for the engine TODO: Generate a comments scaffold (maybe?) for the engine From 765d3e955fdd4fec038c64bceacb60665a0aabbf Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Fri, 7 Oct 2011 09:56:50 +1100 Subject: [PATCH 09/15] [engines guide] Add TODO for mentioning rails s and rails c --- railties/guides/source/engines.textile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index 7b1c0a59e2..e131264842 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -156,6 +156,8 @@ TODO: Brief explanation of what this engine is going to be doing and what we wil TODO: Generate a posts scaffold (maybe?) for the engine TODO: Generate a comments scaffold (maybe?) for the engine +TODO: Mention usage of `rails s` and `rails c` within the context of an engine. + h3. Hooking into application TODO: Application will provide a User foundation class which the engine hooks into through a configuration setting, configurable in the application's initializers. The engine will be mounted at the +/blog+ path in the application. From da030cf9cb335c2fd3deea3cdd474fa5c69fde48 Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Fri, 7 Oct 2011 10:07:29 +1100 Subject: [PATCH 10/15] [engines guide] final line change --- railties/guides/source/engines.textile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index e131264842..201dbd542e 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -165,4 +165,5 @@ TODO: Application will provide a User foundation class which the engine hooks in h3. Overriding engine functionality TODO: Cover how to override engine functionality in the engine, such as controllers and views. -IDEA: I like Devise's +devise :controllers => { "sessions" => "sessions" }+ idea. Perhaps we could incorporate that into the guide? \ No newline at end of file +IDEA: I like Devise's +devise :controllers => { "sessions" => "sessions" }+ idea. Perhaps we could incorporate that into the guide? + From 9e6d43f9c9d7973aee9e1219aac00df3d3f49205 Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Mon, 10 Oct 2011 08:42:27 +1100 Subject: [PATCH 11/15] [engines guide] finish covering what the scaffold generator does within an engine --- railties/guides/source/engines.textile | 44 ++++++++++++++++++++++++-- 1 file changed, 42 insertions(+), 2 deletions(-) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index 201dbd542e..b495b175e3 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -152,8 +152,48 @@ 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. -TODO: Brief explanation of what this engine is going to be doing and what we will have once we are done. -TODO: Generate a posts scaffold (maybe?) for the engine +Next, the +scaffold_controller+ generator is invoked, generating a controlled 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+). + +Everything this generator has generated is neatly namespaced. The controller's class is defined within the +Blorgh+ module: + + +module Blorgh + class PostsController < ApplicationController + ... + end +end + + +NOTE: The +ApplicationController+ class being inherited from here is the +Blorgh::ApplicationController+, not an application's +ApplicationController+. + +The helper is also namespaced: + + +module Blorgh + class PostsHelper + ... + end +end + + +This helps prevent conflicts with any other engine or application that may have a post resource also. + +Finally, two files that are the assets for this resource are generated, +app/assets/javascripts/blorgh/posts.js+ and +app/assets/javascripts/blorgh/posts.css+. You'll see how to use these a little later. + +By default, the scaffold styling is not applied to the engine as the engine's layout file, +app/views/blorgh/application.html.erb+ doesn't load it. To make this apply, insert this line into the ++ tag of this layout: + + +<%= stylesheet_link_tag "scaffold" %> + + +You can see what the engine has so far by running +rake db:migrate+ at the root of our engine to run the migration generated by the scaffold generator, and then running +rails server+. When you open +http://localhost:3000/blorgh/posts+ you will see the default scaffold that has been generated. + +!images/engines_scaffold.png(Blank engine scaffold)! + +Click around! You've just generated your first engine's first functions. + +h4. Generating a comments resource + TODO: Generate a comments scaffold (maybe?) for the engine TODO: Mention usage of `rails s` and `rails c` within the context of an engine. From be01aa6c9b4adb4f95b2c86b13959d1bab16bc58 Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Mon, 10 Oct 2011 08:42:47 +1100 Subject: [PATCH 12/15] [engines guide] amend two TODOs for further things in this guide --- railties/guides/source/engines.textile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index b495b175e3..f53611c310 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -196,7 +196,7 @@ h4. Generating a comments resource TODO: Generate a comments scaffold (maybe?) for the engine -TODO: Mention usage of `rails s` and `rails c` within the context of an engine. +TODO: Mention usage of `rails c` within the context of an engine. h3. Hooking into application @@ -206,4 +206,5 @@ h3. Overriding engine functionality TODO: Cover how to override engine functionality in the engine, such as controllers and views. IDEA: I like Devise's +devise :controllers => { "sessions" => "sessions" }+ idea. Perhaps we could incorporate that into the guide? +TODO: Mention how to use assets within an engine? From 44fc397c801aa09f2b5438f65ab7adb4482d58be Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Mon, 10 Oct 2011 20:10:35 +1100 Subject: [PATCH 13/15] Fix rails/generators/base.rb documentation for generator lookup --- railties/lib/rails/generators/base.rb | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/railties/lib/rails/generators/base.rb b/railties/lib/rails/generators/base.rb index b9dc31457a..911f80cf3a 100644 --- a/railties/lib/rails/generators/base.rb +++ b/railties/lib/rails/generators/base.rb @@ -91,7 +91,7 @@ module Rails # # The lookup in this case for test_unit as input is: # - # "test_unit:awesome", "test_unit" + # "test_framework:awesome", "test_framework" # # Which is not the desired the lookup. You can change it by providing the # :as option: @@ -102,7 +102,7 @@ module Rails # # And now it will lookup at: # - # "test_unit:controller", "test_unit" + # "test_framework:controller", "test_framework" # # Similarly, if you want it to also lookup in the rails namespace, you just # need to provide the :base value: @@ -113,7 +113,7 @@ module Rails # # And the lookup is exactly the same as previously: # - # "rails:test_unit", "test_unit:controller", "test_unit" + # "rails:test_framework", "test_framework:controller", "test_framework" # # ==== Switches # From 59c9825be5a570ef8d5cec1ec5bd9c6c06843f7e Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Mon, 10 Oct 2011 21:03:55 +1100 Subject: [PATCH 14/15] [engines guide] cover generating the comment resource --- railties/guides/source/engines.textile | 86 +++++++++++++++++++++++++- 1 file changed, 84 insertions(+), 2 deletions(-) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index f53611c310..e531bc7507 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -192,11 +192,93 @@ You can see what the engine has so far by running +rake db:migrate+ at the root Click around! You've just generated your first engine's first functions. +If you'd rather play around in the console, +rails console+ will also work just like a Rails application. Remember: the +Post+ model is namespaced, so to reference it you must call it as +Blorgh::Post+. + + + >> Blorgh::Post.find(1) + => # + + h4. Generating a comments resource -TODO: Generate a comments scaffold (maybe?) for the engine +Now that the engine has the ability to create new blog posts, it only makes sense to add commenting functionality as well. + +To do this, you can run the scaffold generator this time and tell it to generate a +Comment+ resource instead, with the table having two columns: a +post_id+ integer and +text+ text column. + + +$ rails generate scaffold Comment post_id:integer text:text + + +This generator call will generate almost the same files as it did the first time we called it for generating the +Post+ resource, but this time the files will be called things such as +app/controllers/blorgh/comments_controller.rb+ and +app/models/blorgh/comment.rb+. + +There's a few things wrong with how this generator has worked. It would be better if the comments resource was nested inside the posts resource in the routes, and if the controller created new comment entries inside a post. These are two very easy things to fix up. + +The +resources+ line from this generator is placed into the +config/routes.rb+ by the generator, but you're going to want to have comments nested underneath a post, and so it's a good idea to change these lines in the +config/routes.rb+ file: + + +Blorgh::Engine.routes.draw do + resources :comments + + resources :posts + +end + + +Into these: + + + Blorgh::Engine.routes.draw do + resources :posts do + resources :comments + end + end + + +That fixes the routes. For the controller, it's just as easy. When a request is made to this controller, it will be in the form of +post/:post_id/comments+. In order to find the comments that are being requested, the post is going to need to be fetched using something such as: + + +post = Post.find(params[:id]) + + +Then to get the comments for this post it would be as simple as: + + +post.comments + + +Alternatively, the query to fetch the comments in actions such as the +index+ action would need to be changed from +Comment.all+ into +Comment.find_all_by_post_id(params[:post_id])+. However, the first way is cleaner and so it should be done that way. + +To fetch the post in the controller, add a +before_filter+ into the controller's class definition like this: + + +module Blorgh + class CommentsController < ApplicationController + before_filter :load_post + ... + end +end + + +This +before_filter+ will call the +load_post+ method before every request that comes into this controller. This method should be defined as a +private+ method after all the actions in the controller: + + +module Blorgh + class CommentsController < ApplicationController + before_filter :load_post + + # actions go here + + private + + def load_post + @post = Post.find(params[:post_id]) + end + end +end + + +With the post being loaded, the queries in the controller need to be altered in order to query within the scope of the relative post. All occurrences of +Comment+ in this controller should now be replaced with +@post.comments+ so that the queries are correctly scoped. -TODO: Mention usage of `rails c` within the context of an engine. h3. Hooking into application From 9c9583fa9be215875e6eacee3290dc46280f9a20 Mon Sep 17 00:00:00 2001 From: Ryan Bigg Date: Mon, 10 Oct 2011 21:04:08 +1100 Subject: [PATCH 15/15] [engines guide] add TODO for RedCarpet example --- railties/guides/source/engines.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile index e531bc7507..db2db05e57 100644 --- a/railties/guides/source/engines.textile +++ b/railties/guides/source/engines.textile @@ -289,4 +289,4 @@ h3. Overriding engine functionality TODO: Cover how to override engine functionality in the engine, such as controllers and views. IDEA: I like Devise's +devise :controllers => { "sessions" => "sessions" }+ idea. Perhaps we could incorporate that into the guide? TODO: Mention how to use assets within an engine? - +TODO: Mention how to depend on external gems, like RedCarpet.