annotate .svn/pristine/6f/6f3eae848dd2627dfa6aa6d53a27862ad05c9e96.svn-base @ 1519:afce8026aaeb redmine-2.4-integration

Merge from branch "live"
author Chris Cannam
date Tue, 09 Sep 2014 09:34:53 +0100
parents cbb26bc654de
children
rev   line source
Chris@909 1 The engines plugin enhances Rails' own plugin framework, making it simple to share controllers, helpers, models, public assets, routes and migrations in plugins.
Chris@909 2
Chris@909 3 For more information, see http://rails-engines.org
Chris@909 4
Chris@909 5 = Using the plugin
Chris@909 6
Chris@909 7 Once you've installed the engines plugin, you'll need to add a single line to the top of config/environment.rb:
Chris@909 8
Chris@909 9 require File.join(File.dirname(__FILE__), '../vendor/plugins/engines/boot')
Chris@909 10
Chris@909 11 You should add this line just below the require for Rails' own boot.rb file. This will enabled the enhanced plugin loading mechanism automatically for you (i.e. you don't need to set config.plugin_loader manually).
Chris@909 12
Chris@909 13 With that aside, you're now ready to start using more powerful plugins in your application. Read on to find out more about what the engines plugin enables.
Chris@909 14
Chris@909 15
Chris@909 16 == Better plugins
Chris@909 17
Chris@909 18 In addition to the regular set of plugin-supported files (lib, init.rb, tasks, generators, tests), plugins can carry the following when the engines plugin is also installed.
Chris@909 19
Chris@909 20
Chris@909 21 === Controllers, Helpers, and Views
Chris@909 22
Chris@909 23 Include these files in an <tt>app</tt> directory just like you would in a normal Rails application. If you need to override a method, view or partial, create the corresponding file in your main <tt>app</tt> directory and it will be used instead.
Chris@909 24
Chris@909 25 * Controllers & Helpers: See Engines::RailsExtensions::Dependencies for more information.
Chris@909 26 * Views: now handled almost entirely by ActionView itself (see Engines::Plugin#add_plugin_view_paths for more information)
Chris@909 27
Chris@909 28 === Models
Chris@909 29
Chris@909 30 Model code can similarly be placed in an <tt>app/models/</tt> directory. Unfortunately, it's not possible to automatically override methods within a model; if your application needs to change the way a model behaves, consider creating a subclass, or replacing the model entirely within your application's <tt>app/models/</tt> directory. See Engines::RailsExtensions::Dependencies for more information.
Chris@909 31
Chris@909 32 IMPORTANT NOTE: when you load code from within plugins, it is typically not handled well by Rails in terms of unloading and reloading changes. Look here for more information - http://rails-engines.org/development/common-issues-when-overloading-code-from-plugins/
Chris@909 33
Chris@909 34 === Routes
Chris@909 35
Chris@909 36 Include your route declarations in a <tt>routes.rb</tt> file at the root of your plugins, e.g.:
Chris@909 37
Chris@909 38 connect "/my/url", :controller => "some_controller"
Chris@909 39 my_named_route "do_stuff", :controller => "blah", :action => "stuff"
Chris@909 40 # etc.
Chris@909 41
Chris@909 42 You can then load these files into your application by declaring their inclusion in the application's <tt>config/routes.rb</tt>:
Chris@909 43
Chris@909 44 map.from_plugin :plugin_name
Chris@909 45
Chris@909 46 See Engines::RailsExtensions::Routing for more information.
Chris@909 47
Chris@909 48 === Migrations
Chris@909 49
Chris@909 50 Migrations record the changes in your database as your application evolves. With engines 1.2, migrations from plugins can also join in this evolution as first-class entities. To add migrations to a plugin, include a <tt>db/migrate/</tt> folder and add migrations there as normal. These migrations can then be integrated into the main flow of database evolution by running the plugin_migration generator:
Chris@909 51
Chris@909 52 script/generate plugin_migration
Chris@909 53
Chris@909 54 This will produce a migration in your application. Running this migration (via <tt>rake db:migrate</tt>, as normal) will migrate the database according to the latest migrations in each plugin. See Engines::RailsExtensions::Migrations for more information.
Chris@909 55
Chris@909 56
Chris@909 57 === More powerful Rake tasks
Chris@909 58
Chris@909 59 The engines plugin enhances and adds to the suite of default rake tasks for working with plugins. The <tt>doc:plugins</tt> task now includes controllers, helpers and models under <tt>app</tt>, and anything other code found under the plugin's <tt>code_paths</tt> attribute. New testing tasks have been added to run unit, functional and integration tests from plugins, whilst making it easier to load fixtures from plugins. See Engines::Testing for more details about testing, and run
Chris@909 60
Chris@909 61 rake -T
Chris@909 62
Chris@909 63 to see the set of rake tasks available.
Chris@909 64
Chris@909 65 = Testing the engines plugin itself
Chris@909 66
Chris@909 67 Because of the way the engines plugin modifies Rails, the simplest way to consistently test it against multiple versions is by generating a test harness application - a full Rails application that includes tests to verify the engines plugin behaviour in a real, running environment.
Chris@909 68
Chris@909 69 Run the tests like this:
Chris@909 70
Chris@909 71 $ cd engines
Chris@909 72 $ rake test
Chris@909 73
Chris@909 74 This will generate a test_app directory within the engines plugin (using the default 'rails' command), import tests and code into that application and then run the test suite.
Chris@909 75
Chris@909 76 If you wish to test against a specific version of Rails, run the tests with the RAILS environment variable set to the local directory containing your Rails checkout
Chris@909 77
Chris@909 78 $ rake test RAILS=/Users/james/Code/rails_edge_checkout
Chris@909 79
Chris@909 80 Alternatively, you can clone the latest version of Rails ('edge rails') from github like so:
Chris@909 81
Chris@909 82 $ rake test RAILS=edge
Chris@909 83