From 7eb249291d1c8a8af14c52de4767a36ba8f924e3 Mon Sep 17 00:00:00 2001 From: Jeff Dean Date: Fri, 14 Nov 2008 02:29:12 -0500 Subject: Plugin guide: added model and controller sections --- railties/doc/guides/html/creating_plugins.html | 355 ++++++++++++++------- .../guides/source/creating_plugins/controllers.txt | 59 ++++ .../doc/guides/source/creating_plugins/index.txt | 8 +- .../creating_plugins/migration_generator.txt | 5 +- .../doc/guides/source/creating_plugins/models.txt | 76 +++++ .../source/creating_plugins/odds_and_ends.txt | 22 -- .../guides/source/creating_plugins/test_setup.txt | 3 + 7 files changed, 384 insertions(+), 144 deletions(-) create mode 100644 railties/doc/guides/source/creating_plugins/controllers.txt create mode 100644 railties/doc/guides/source/creating_plugins/models.txt (limited to 'railties/doc/guides') diff --git a/railties/doc/guides/html/creating_plugins.html b/railties/doc/guides/html/creating_plugins.html index 3e67c34b4f..3fa7bff260 100644 --- a/railties/doc/guides/html/creating_plugins.html +++ b/railties/doc/guides/html/creating_plugins.html @@ -235,10 +235,7 @@ ul#navMain {
  • - Create a squawk_info_for view helper -
    • -
  • - Create a migration generator + Create a generator -

    5.1. Testing generators

    +

    4.1. Testing generators

    Many rails plugin authors do not test their generators, however testing generators is quite simple. A typical generator test does the following:

    • @@ -1063,7 +994,7 @@ http://www.gnu.org/software/src-highlite --> require 'rails_generator/scripts/generate' require 'rails_generator/scripts/destroy' -class YaffleTest < Test::Unit::TestCase +class GeneratorTest < Test::Unit::TestCase def fake_rails_root File.join(File.dirname(__FILE__), 'rails_root') @@ -1091,7 +1022,7 @@ http://www.gnu.org/software/src-highlite --> end

    You can run rake from the plugin directory to see this fail. Unless you are doing more advanced generator commands it typically suffices to just test the Generate script, and trust that rails will handle the Destroy and Update commands for you.

    -

    5.2. Adding to the manifest

    +

    4.2. Adding to the manifest

    This example will demonstrate how to use one of the built-in generator methods named migration_template to create a migration file. To start, update your generator file to look like this:

    vendor/plugins/yaffle/generators/yaffle/yaffle_generator.rb

    @@ -1126,7 +1057,7 @@ http://www.gnu.org/software/src-highlite -->

    The generator creates a new file in db/migrate with a timestamp and an add_column statement. It reuses the built in rails migration_template method, and reuses the built-in rails migration template.

    It's courteous to check to see if table names are being pluralized whenever you create a generator that needs to be aware of table names. This way people using your generator won't have to manually change the generated files if they've turned pluralization off.

    -

    5.3. Manually test the generator

    +

    4.3. Manually test the generator

    To run the generator, type the following at the command line:

    @@ -1149,7 +1080,7 @@ http://www.gnu.org/software/src-highlite --> end end
    -

    5.4. The USAGE file

    +

    4.4. The USAGE file

    Rails ships with several built-in generators. You can see all of the generators available to you by typing the following at the command line:

    @@ -1176,7 +1107,7 @@ Example: db/migrate/TIMESTAMP_add_yaffle_fields_to_hickwall
    -

    6. Add a custom generator command

    +

    5. Add a custom generator command

    You may have noticed above that you can used one of the built-in rails migration commands migration_template. If your plugin needs to add and remove lines of text from existing files you will need to write your own generator methods.

    This section describes how you you can create your own commands to add and remove a line of text from routes.rb. This example creates a very simple method that adds or removes a text file.

    @@ -1265,7 +1196,215 @@ http://www.gnu.org/software/src-highlite --> end
    -

    7. Add a Custom Route

    +

    6. Add a model

    +
    +

    This section describes how to add a model named Woodpecker to your plugin that will behave the same as a model in your main app. When storing models, controllers, views and helpers in your plugin, it's customary to keep them in directories that match the rails directories. For this example, create a file structure like this:

    +
    +
    +
    vendor/plugins/yaffle/
+|-- lib
+|   |-- app
+|   |   |-- controllers
+|   |   |-- helpers
+|   |   |-- models
+|   |   |   `-- woodpecker.rb
+|   |   `-- views
+|   |-- yaffle
+|   |   |-- acts_as_yaffle.rb
+|   |   |-- commands.rb
+|   |   `-- core_ext.rb
+|   `-- yaffle.rb
    +
    +

    As always, start with a test:

    +

    vendor/plugins/yaffle/yaffle/woodpecker_test.rb:

    +
    +
    +
    require File.dirname(__FILE__) + '/test_helper.rb'
+
+class WoodpeckerTest < Test::Unit::TestCase
+  load_schema
+
+  def test_woodpecker
+    assert_kind_of Woodpecker, Woodpecker.new
+  end
+end
+
    +

    This is just a simple test to make sure the class is being loaded correctly. After watching it fail with rake, you can make it pass like so:

    +

    vendor/plugins/yaffle/lib/yaffle.rb:

    +
    +
    +
    %w{ models }.each do |dir|
+  path = File.join(File.dirname(__FILE__), 'app', dir)
+  $LOAD_PATH << path
+  ActiveSupport::Dependencies.load_paths << path
+  ActiveSupport::Dependencies.load_once_paths.delete(path)
+end
+
    +

    Adding directories to the load path makes them appear just like files in the the main app directory - except that they are only loaded once, so you have to restart the web server to see the changes in the browser. Removing directories from the load_once_paths allow those changes to picked up as soon as you save the file - without having to restart the web server. This is particularly useful as you develop the plugin.

    +

    vendor/plugins/yaffle/lib/app/models/woodpecker.rb:

    +
    +
    +
    class Woodpecker < ActiveRecord::Base
+end
+
    +

    Finally, add the following to your plugin's schema.rb:

    +

    vendor/plugins/yaffle/test/schema.rb:

    +
    +
    +
    ActiveRecord::Schema.define(:version => 0) do
+  create_table :woodpeckers, :force => true do |t|
+    t.string :name
+  end
+end
+
    +

    Now your test should be passing, and you should be able to use the Woodpecker model from within your rails app, and any changes made to it are reflected immediately when running in development mode.

    +
    +

    7. Add a controller

    +
    +

    This section describes how to add a controller named woodpeckers to your plugin that will behave the same as a controller in your main app. This is very similar to adding a model.

    +

    You can test your plugin's controller as you would test any other controller:

    +

    vendor/plugins/yaffle/yaffle/woodpeckers_controller_test.rb:

    +
    +
    +
    require File.dirname(__FILE__) + '/test_helper.rb'
+require 'woodpeckers_controller'
+require 'action_controller/test_process'
+
+class WoodpeckersController; def rescue_action(e) raise e end; end
+
+class WoodpeckersControllerTest < Test::Unit::TestCase
+  def setup
+    @controller = WoodpeckersController.new
+    @request = ActionController::TestRequest.new
+    @response = ActionController::TestResponse.new
+  end
+
+  def test_index
+    get :index
+    assert_response :success
+  end
+end
+
    +

    This is just a simple test to make sure the controller is being loaded correctly. After watching it fail with rake, you can make it pass like so:

    +

    vendor/plugins/yaffle/lib/yaffle.rb:

    +
    +
    +
    %w{ models controllers }.each do |dir|
+  path = File.join(File.dirname(__FILE__), 'app', dir)
+  $LOAD_PATH << path
+  ActiveSupport::Dependencies.load_paths << path
+  ActiveSupport::Dependencies.load_once_paths.delete(path)
+end
+
    +

    vendor/plugins/yaffle/lib/app/controllers/woodpeckers_controller.rb:

    +
    +
    +
    class WoodpeckersController < ActionController::Base
+
+  def index
+    render :text => "Squawk!"
+  end
+
+end
+
    +

    Now your test should be passing, and you should be able to use the Woodpeckers controller in your app. If you add a route for the woodpeckers controller you can start up your server and go to http://localhost:3000/woodpeckers to see your controller in action.

    +
    +

    8. Create a squawk_info_for view helper

    +
    +

    Creating a view helper is a 3-step process:

    +
      +
    • +

      +Add an appropriately named file to the lib directory. +

      +
      • +
    • +

      +Require the file and hooks in init.rb. +

      +
      • +
    • +

      +Write the tests. +

      +
      • +
    +

    First, create the test to define the functionality you want:

    +

    vendor/plugins/yaffle/test/view_helpers_test.rb

    +
    +
    +
    require File.dirname(__FILE__) + '/test_helper.rb'
+include YaffleViewHelper
+
+class ViewHelpersTest < Test::Unit::TestCase
+  def test_squawk_info_for_should_return_the_text_and_date
+    time = Time.now
+    hickwall = Hickwall.new
+    hickwall.last_squawk = "Hello World"
+    hickwall.last_squawked_at = time
+    assert_equal "Hello World, #{time.to_s}", squawk_info_for(hickwall)
+  end
+end
+
    +

    Then add the following statements to init.rb:

    +

    vendor/plugins/yaffle/init.rb

    +
    +
    +
    require "view_helpers"
+ActionView::Base.send :include, YaffleViewHelper
+
    +

    Then add the view helpers file and

    +

    vendor/plugins/yaffle/lib/view_helpers.rb

    +
    +
    +
    module YaffleViewHelper
+  def squawk_info_for(yaffle)
+    returning "" do |result|
+      result << yaffle.read_attribute(yaffle.class.yaffle_text_field)
+      result << ", "
+      result << yaffle.read_attribute(yaffle.class.yaffle_date_field).to_s
+    end
+  end
+end
+
    +

    You can also test this in script/console by using the helper method:

    +
    +
    +
    $ ./script/console
+>> helper.squawk_info_for(@some_yaffle_instance)
    +
    +
    +

    9. Add a Custom Route

    Testing routes in plugins can be complex, especially if the controllers are also in the plugin itself. Jamis Buck showed a great example of this in http://weblog.jamisbuck.org/2006/10/26/monkey-patching-rails-extending-routes-2.

    vendor/plugins/yaffle/test/routing_test.rb

    @@ -1338,9 +1477,9 @@ http://www.gnu.org/software/src-highlite -->

    You can also see if your routes work by running rake routes from your app directory.

    -

    8. Odds and ends

    +

    10. Odds and ends

    -

    8.1. Generate RDoc Documentation

    +

    10.1. Generate RDoc Documentation

    Once your plugin is stable, the tests pass on all database and you are ready to deploy do everyone else a favor and document it! Luckily, writing documentation for your plugin is easy.

    The first step is to update the README file with detailed information about how to use your plugin. A few key things to include are:

      @@ -1372,25 +1511,7 @@ Warning, gotchas or tips that might help save users time. 
      rake rdoc
    -

    8.2. Store models, views, helpers, and controllers in your plugins

    -

    You can easily store models, views, helpers and controllers in plugins. Just create a folder for each in the lib folder, add them to the load path and remove them from the load once path:

    -
    -
    -
    # File: vendor/plugins/yaffle/init.rb
-
-%w{ models controllers helpers }.each do |dir|
-  path = File.join(directory, 'lib', dir)
-  $LOAD_PATH << path
-  Dependencies.load_paths << path
-  Dependencies.load_once_paths.delete(path)
-end
-
    -

    Adding directories to the load path makes them appear just like files in the the main app directory - except that they are only loaded once, so you have to restart the web server to see the changes in the browser.

    -

    Adding directories to the load once paths allow those changes to picked up as soon as you save the file - without having to restart the web server.

    -

    8.3. Write custom Rake tasks in your plugin

    +

    10.2. Write custom Rake tasks in your plugin

    When you created the plugin with the built-in rails generator, it generated a rake file for you in vendor/plugins/yaffle/tasks/yaffle.rake. Any rake task you add here will be available to the app.

    Many plugin authors put all of their rake tasks into a common namespace that is the same as the plugin, like so:

    vendor/plugins/yaffle/tasks/yaffle.rake

    @@ -1412,7 +1533,7 @@ http://www.gnu.org/software/src-highlite --> 
    yaffle:squawk             # Prints out the word 'Yaffle'

    You can add as many files as you want in the tasks directory, and if they end in .rake Rails will pick them up.

    -

    8.4. Store plugins in alternate locations

    +

    10.3. Store plugins in alternate locations

    You can store plugins wherever you want - you just have to add those plugins to the plugins path in environment.rb.

    Since the plugin is only loaded after the plugin paths are defined, you can't redefine this in your plugins - but it may be good to now.

    You can even store plugins inside of other plugins for complete plugin madness!

    @@ -1423,14 +1544,14 @@ http://www.lorenzobettini.it http://www.gnu.org/software/src-highlite --> 
    config.plugin_paths << File.join(RAILS_ROOT,"vendor","plugins","yaffle","lib","plugins")
    -

    8.5. Create your own Plugin Loaders and Plugin Locators

    +

    10.4. Create your own Plugin Loaders and Plugin Locators

    If the built-in plugin behavior is inadequate, you can change almost every aspect of the location and loading process. You can write your own plugin locators and plugin loaders, but that's beyond the scope of this tutorial.

    -

    8.6. Use Custom Plugin Generators

    +

    10.5. Use Custom Plugin Generators

    If you are an RSpec fan, you can install the rspec_plugin_generator gem, which will generate the spec folder and database for you. See http://github.com/pat-maddox/rspec-plugin-generator/tree/master.

    -

    9. Appendix

    +

    11. Appendix

    -

    9.1. References

    +

    11.1. References

    • @@ -1453,7 +1574,7 @@ http://www.gnu.org/software/src-highlite -->

    -

    9.2. Final plugin directory structure

    +

    11.2. Final plugin directory structure

    The final plugin should have a directory structure that looks something like this:

    diff --git a/railties/doc/guides/source/creating_plugins/controllers.txt b/railties/doc/guides/source/creating_plugins/controllers.txt new file mode 100644 index 0000000000..ee408adb1d --- /dev/null +++ b/railties/doc/guides/source/creating_plugins/controllers.txt @@ -0,0 +1,59 @@ +== Add a controller == + +This section describes how to add a controller named 'woodpeckers' to your plugin that will behave the same as a controller in your main app. This is very similar to adding a model. + +You can test your plugin's controller as you would test any other controller: + +*vendor/plugins/yaffle/yaffle/woodpeckers_controller_test.rb:* + +[source, ruby] +---------------------------------------------- +require File.dirname(__FILE__) + '/test_helper.rb' +require 'woodpeckers_controller' +require 'action_controller/test_process' + +class WoodpeckersController; def rescue_action(e) raise e end; end + +class WoodpeckersControllerTest < Test::Unit::TestCase + def setup + @controller = WoodpeckersController.new + @request = ActionController::TestRequest.new + @response = ActionController::TestResponse.new + end + + def test_index + get :index + assert_response :success + end +end +---------------------------------------------- + +This is just a simple test to make sure the controller is being loaded correctly. After watching it fail with `rake`, you can make it pass like so: + +*vendor/plugins/yaffle/lib/yaffle.rb:* + +[source, ruby] +---------------------------------------------- +%w{ models controllers }.each do |dir| + path = File.join(File.dirname(__FILE__), 'app', dir) + $LOAD_PATH << path + ActiveSupport::Dependencies.load_paths << path + ActiveSupport::Dependencies.load_once_paths.delete(path) +end +---------------------------------------------- + + +*vendor/plugins/yaffle/lib/app/controllers/woodpeckers_controller.rb:* + +[source, ruby] +---------------------------------------------- +class WoodpeckersController < ActionController::Base + + def index + render :text => "Squawk!" + end + +end +---------------------------------------------- + +Now your test should be passing, and you should be able to use the Woodpeckers controller in your app. If you add a route for the woodpeckers controller you can start up your server and go to http://localhost:3000/woodpeckers to see your controller in action. diff --git a/railties/doc/guides/source/creating_plugins/index.txt b/railties/doc/guides/source/creating_plugins/index.txt index bd7dfe65c3..67e6aec39c 100644 --- a/railties/doc/guides/source/creating_plugins/index.txt +++ b/railties/doc/guides/source/creating_plugins/index.txt @@ -35,12 +35,16 @@ include::core_ext.txt[] include::acts_as_yaffle.txt[] -include::view_helper.txt[] - include::migration_generator.txt[] include::generator_method.txt[] +include::models.txt[] + +include::controllers.txt[] + +include::view_helper.txt[] + include::custom_route.txt[] include::odds_and_ends.txt[] diff --git a/railties/doc/guides/source/creating_plugins/migration_generator.txt b/railties/doc/guides/source/creating_plugins/migration_generator.txt index 743d512132..f4fc32481c 100644 --- a/railties/doc/guides/source/creating_plugins/migration_generator.txt +++ b/railties/doc/guides/source/creating_plugins/migration_generator.txt @@ -1,4 +1,4 @@ -== Create a migration generator == +== Create a generator == Many plugins ship with generators. When you created the plugin above, you specified the --with-generator option, so you already have the generator stubs in 'vendor/plugins/yaffle/generators/yaffle'. @@ -30,7 +30,7 @@ require 'rails_generator' require 'rails_generator/scripts/generate' require 'rails_generator/scripts/destroy' -class YaffleTest < Test::Unit::TestCase +class GeneratorTest < Test::Unit::TestCase def fake_rails_root File.join(File.dirname(__FILE__), 'rails_root') @@ -124,7 +124,6 @@ end ------------------------------------------------------------------ - === The USAGE file === Rails ships with several built-in generators. You can see all of the generators available to you by typing the following at the command line: diff --git a/railties/doc/guides/source/creating_plugins/models.txt b/railties/doc/guides/source/creating_plugins/models.txt new file mode 100644 index 0000000000..458edec80a --- /dev/null +++ b/railties/doc/guides/source/creating_plugins/models.txt @@ -0,0 +1,76 @@ +== Add a model == + +This section describes how to add a model named 'Woodpecker' to your plugin that will behave the same as a model in your main app. When storing models, controllers, views and helpers in your plugin, it's customary to keep them in directories that match the rails directories. For this example, create a file structure like this: + +--------------------------------------------------------- +vendor/plugins/yaffle/ +|-- lib +| |-- app +| | |-- controllers +| | |-- helpers +| | |-- models +| | | `-- woodpecker.rb +| | `-- views +| |-- yaffle +| | |-- acts_as_yaffle.rb +| | |-- commands.rb +| | `-- core_ext.rb +| `-- yaffle.rb +--------------------------------------------------------- + +As always, start with a test: + +*vendor/plugins/yaffle/yaffle/woodpecker_test.rb:* + +[source, ruby] +---------------------------------------------- +require File.dirname(__FILE__) + '/test_helper.rb' + +class WoodpeckerTest < Test::Unit::TestCase + load_schema + + def test_woodpecker + assert_kind_of Woodpecker, Woodpecker.new + end +end +---------------------------------------------- + +This is just a simple test to make sure the class is being loaded correctly. After watching it fail with `rake`, you can make it pass like so: + +*vendor/plugins/yaffle/lib/yaffle.rb:* + +[source, ruby] +---------------------------------------------- +%w{ models }.each do |dir| + path = File.join(File.dirname(__FILE__), 'app', dir) + $LOAD_PATH << path + ActiveSupport::Dependencies.load_paths << path + ActiveSupport::Dependencies.load_once_paths.delete(path) +end +---------------------------------------------- + +Adding directories to the load path makes them appear just like files in the the main app directory - except that they are only loaded once, so you have to restart the web server to see the changes in the browser. Removing directories from the 'load_once_paths' allow those changes to picked up as soon as you save the file - without having to restart the web server. This is particularly useful as you develop the plugin. + + +*vendor/plugins/yaffle/lib/app/models/woodpecker.rb:* + +[source, ruby] +---------------------------------------------- +class Woodpecker < ActiveRecord::Base +end +---------------------------------------------- + +Finally, add the following to your plugin's 'schema.rb': + +*vendor/plugins/yaffle/test/schema.rb:* + +[source, ruby] +---------------------------------------------- +ActiveRecord::Schema.define(:version => 0) do + create_table :woodpeckers, :force => true do |t| + t.string :name + end +end +---------------------------------------------- + +Now your test should be passing, and you should be able to use the Woodpecker model from within your rails app, and any changes made to it are reflected immediately when running in development mode. \ No newline at end of file diff --git a/railties/doc/guides/source/creating_plugins/odds_and_ends.txt b/railties/doc/guides/source/creating_plugins/odds_and_ends.txt index a52e1c8fdb..e328c04a79 100644 --- a/railties/doc/guides/source/creating_plugins/odds_and_ends.txt +++ b/railties/doc/guides/source/creating_plugins/odds_and_ends.txt @@ -19,28 +19,6 @@ Once your comments are good to go, navigate to your plugin directory and run: rake rdoc - -=== Store models, views, helpers, and controllers in your plugins === - -You can easily store models, views, helpers and controllers in plugins. Just create a folder for each in the lib folder, add them to the load path and remove them from the load once path: - -[source, ruby] ---------------------------------------------------------- -# File: vendor/plugins/yaffle/init.rb - -%w{ models controllers helpers }.each do |dir| - path = File.join(directory, 'lib', dir) - $LOAD_PATH << path - Dependencies.load_paths << path - Dependencies.load_once_paths.delete(path) -end ---------------------------------------------------------- - -Adding directories to the load path makes them appear just like files in the the main app directory - except that they are only loaded once, so you have to restart the web server to see the changes in the browser. - -Adding directories to the load once paths allow those changes to picked up as soon as you save the file - without having to restart the web server. - - === Write custom Rake tasks in your plugin === When you created the plugin with the built-in rails generator, it generated a rake file for you in 'vendor/plugins/yaffle/tasks/yaffle.rake'. Any rake task you add here will be available to the app. diff --git a/railties/doc/guides/source/creating_plugins/test_setup.txt b/railties/doc/guides/source/creating_plugins/test_setup.txt index 9e6763bc30..6ea2a37fa7 100644 --- a/railties/doc/guides/source/creating_plugins/test_setup.txt +++ b/railties/doc/guides/source/creating_plugins/test_setup.txt @@ -115,6 +115,9 @@ ActiveRecord::Schema.define(:version => 0) do t.string :last_tweet t.datetime :last_tweeted_at end + create_table :woodpeckers, :force => true do |t| + t.string :name + end end ---------------------------------------------- -- cgit v1.2.3