diff options
Diffstat (limited to 'railties/guides/source/plugins.textile')
| -rw-r--r-- | railties/guides/source/plugins.textile | 41 |
1 files changed, 21 insertions, 20 deletions
diff --git a/railties/guides/source/plugins.textile b/railties/guides/source/plugins.textile index d486e8ade3..2eb71e49c4 100644 --- a/railties/guides/source/plugins.textile +++ b/railties/guides/source/plugins.textile @@ -25,33 +25,36 @@ endprologue. h3. Setup -h4. Generating the Plugin Skeleton +Before you continue, take a moment to decide if your new plugin will be potentially shared across different Rails applications. -Rails currently ships with a generator to generate a plugin within a Rails application. Help text is available that will explain -how this generator works. +* If your plugin is specific to your application, your new plugin will be a _vendored plugin_. +* If you think your plugin may be used across applications, build it as a _gemified plugin_. + +h4. Either generate a vendored plugin... + +Use the +rails generate plugin+ command in your Rails root directory + to create a new plugin that will live in the +vendor/plugins+ + directory. See usage and options by asking for help: <shell> -$ rails generate plugin --help +$ rails generate plugin new --help </shell> -This generator places the plugin into the vendor/plugins directory. +h4. Or generate a gemified plugin. -Vendored plugins are useful for quickly prototyping your plugin but current thinking in the Rails community is shifting towards -packaging plugins as gems, especially with the inclusion of Bundler as the Rails dependency manager. -Packaging a plugin as a gem may be overkill for any plugins that will not be shared across projects but doing so from the start makes it easier to share the plugin going forward without adding too much additional overhead during development. +Writing your Rails plugin as a gem, rather than as a vendored plugin, + lets you share your plugin across different rails applications using + RubyGems and Bundler. -Rails 3.1 will ship with a plugin generator that will default to setting up a plugin -as a gem. This tutorial will begin to bridge that gap by demonstrating how to create a gem based plugin using the -"Enginex gem":http://www.github.com/josevalim/enginex. +Rails 3.1 ships with a +rails plugin new+ command which creates a + skeleton for developing any kind of Rails extension with the ability + to run integration tests using a dummy Rails application. See usage + and options by asking for help: <shell> -$ gem install enginex -$ enginex --help -$ enginex yaffle +$ rails plugin --help </shell> -This command will create a new directory named "yaffle" within the current directory. - h3. Testing your newly generated plugin You can navigate to the directory that contains the plugin, run the +bundle install+ command @@ -319,7 +322,7 @@ When you run +rake+ you should see the tests all pass: h4. Add an Instance Method -This plugin will add a method named 'squawk' to any Active Record objects that call 'acts_as_yaffle'. The 'squawk' +This plugin will add a method named 'squawk' to any Active Record objects that call 'acts_as_yaffle'. The 'squawk' method will simply set the value of one of the fields in the database. To start out, write a failing test that shows the behavior you'd like: @@ -387,9 +390,7 @@ Run +rake+ one final time and you should see: 7 tests, 7 assertions, 0 failures, 0 errors, 0 skips </shell> -NOTE: The use of +write_attribute+ to write to the field in model is just one example of how a plugin can -interact with the model, and will not always be the right method to use. For example, you could also -use +send("#{self.class.yaffle_text_field}=", string.to_squawk)+. +NOTE: The use of +write_attribute+ to write to the field in model is just one example of how a plugin can interact with the model, and will not always be the right method to use. For example, you could also use <tt>send("#{self.class.yaffle_text_field}=", string.to_squawk)</tt>. h3. Generators |