railscart 0.0.1

data/starter-app/vendor/plugins/engines/lib/engines/rails_extensions/dependencies.rb

@@ -0,0 +1,145 @@
+# One of the magic features that that engines plugin provides is the ability to
+# override selected methods in controllers and helpers from your application.
+# This is achieved by trapping requests to load those files, and then mixing in
+# code from plugins (in the order the plugins were loaded) before finally loading
+# any versions from the main +app+ directory.
+#
+# The behaviour of this extension is output to the log file for help when
+# debugging.
+#
+# == Example
+#
+# A plugin contains the following controller in <tt>plugin/app/controllers/my_controller.rb</tt>:
+#
+#   class MyController < ApplicationController
+#     def index
+#       @name = "HAL 9000"
+#     end
+#     def list
+#       @robots = Robot.find(:all)
+#     end
+#   end
+#
+# In one application that uses this plugin, we decide that the name used in the
+# index action should be "Robbie", not "HAL 9000". To override this single method,
+# we create the corresponding controller in our application 
+# (<tt>RAILS_ROOT/app/controllers/my_controller.rb</tt>), and redefine the method:
+#
+#   class MyController < ApplicationController
+#     def index
+#       @name = "Robbie"
+#     end
+#   end
+#
+# The list method remains as it was defined in the plugin controller.
+#
+# The same basic principle applies to helpers, and also views and partials (although
+# view overriding is performed in Engines::RailsExtensions::Templates; see that
+# module for more information).
+#
+# === What about models?
+#
+# Unfortunately, it's not possible to provide this kind of magic for models.
+# The only reason why it's possible for controllers and helpers is because
+# they can be recognised by their filenames ("whatever_controller", "jazz_helper"),
+# whereas models appear the same as any other typical Ruby library ("node",
+# "user", "image", etc.). 
+#
+# If mixing were allowed in models, it would mean code mixing for *every* 
+# file that was loaded via +require_or_load+, and this could result in
+# problems where, for example, a Node model might start to include 
+# functionality from another file called "node" somewhere else in the
+# <tt>$LOAD_PATH</tt>.
+#
+# One way to overcome this is to provide model functionality as a module in
+# a plugin, which developers can then include into their own model
+# implementations.
+#
+# Another option is to provide an abstract model (see the ActiveRecord::Base
+# documentation) and have developers subclass this model in their own
+# application if they must.
+#
+# ---
+#
+# The Engines::RailsExtensions::Dependencies module includes a method to
+# override Dependencies.require_or_load, which is called to load code needed
+# by Rails as it encounters constants that aren't defined.
+#
+# This method is enhanced with the code-mixing features described above.
+#
+module Engines::RailsExtensions::Dependencies
+  def self.included(base) #:nodoc:
+    base.class_eval { alias_method_chain :require_or_load, :engine_additions }
+  end
+
+  # Attempt to load the given file from any plugins, as well as the application.
+  # This performs the 'code mixing' magic, allowing application controllers and
+  # helpers to override single methods from those in plugins.
+  # If the file can be found in any plugins, it will be loaded first from those
+  # locations. Finally, the application version is loaded, using Ruby's behaviour
+  # to replace existing methods with their new definitions.
+  #
+  # If <tt>Engines.disable_code_mixing == true</tt>, the first controller/helper on the
+  # <tt>$LOAD_PATH</tt> will be used (plugins' +app+ directories are always lower on the
+  # <tt>$LOAD_PATH</tt> than the main +app+ directory).
+  #
+  # If <tt>Engines.disable_application_code_loading == true</tt>, controllers will
+  # not be loaded from the main +app+ directory *if* they are present in any
+  # plugins.
+  #
+  # Returns true if the file could be loaded (from anywhere); false otherwise -
+  # mirroring the behaviour of +require_or_load+ from Rails (which mirrors
+  # that of Ruby's own +require+, I believe).
+  def require_or_load_with_engine_additions(file_name, const_path=nil)
+    return require_or_load_without_engine_additions(file_name, const_path) if Engines.disable_code_mixing
+
+    file_loaded = false
+
+    # try and load the plugin code first
+    # can't use model, as there's nothing in the name to indicate that the file is a 'model' file
+    # rather than a library or anything else.
+    Engines.code_mixing_file_types.each do |file_type| 
+      # if we recognise this type
+      # (this regexp splits out the module/filename from any instances of app/#{type}, so that
+      #  modules are still respected.)
+      if file_name =~ /^(.*app\/#{file_type}s\/)?(.*_#{file_type})(\.rb)?$/
+        base_name = $2
+        # ... go through the plugins from first started to last, so that
+        # code with a high precedence (started later) will override lower precedence
+        # implementations
+        Engines.plugins.each do |plugin|
+          plugin_file_name = File.expand_path(File.join(plugin.directory, 'app', "#{file_type}s", base_name))
+          Engines.logger.debug("checking plugin '#{plugin.name}' for '#{base_name}'")
+          if File.file?("#{plugin_file_name}.rb")
+            Engines.logger.debug("==> loading from plugin '#{plugin.name}'")
+            file_loaded = true if require_or_load_without_engine_additions(plugin_file_name, const_path)
+          end
+        end
+    
+        # finally, load any application-specific controller classes using the 'proper'
+        # rails load mechanism, EXCEPT when we're testing engines and could load this file
+        # from an engine
+        if Engines.disable_application_code_loading
+          Engines.logger.debug("loading from application disabled.")
+        else
+          # Ensure we are only loading from the /app directory at this point
+          app_file_name = File.join(RAILS_ROOT, 'app', "#{file_type}s", "#{base_name}")
+          if File.file?("#{app_file_name}.rb")
+            Engines.logger.debug("loading from application: #{base_name}")
+            file_loaded = true if require_or_load_without_engine_additions(app_file_name, const_path)
+          else
+            Engines.logger.debug("(file not found in application)")
+          end
+        end        
+      end 
+    end
+
+    # if we managed to load a file, return true. If not, default to the original method.
+    # Note that this relies on the RHS of a boolean || not to be evaluated if the LHS is true.
+    file_loaded || require_or_load_without_engine_additions(file_name, const_path)
+  end  
+end
+
+module ::Dependencies #:nodoc:
+  include Engines::RailsExtensions::Dependencies
+end

data/starter-app/vendor/plugins/engines/lib/engines/rails_extensions/migrations.rb

@@ -0,0 +1,161 @@
+# Contains the enhancements to Rails' migrations system to support the 
+# Engines::Plugin::Migrator. See Engines::RailsExtensions::Migrations for more
+# information.
+
+require "engines/plugin/migrator"
+
+# = Plugins and Migrations: Background
+#
+# Rails uses migrations to describe changes to the databases as your application
+# evolves. Each change to your application - adding and removing models, most
+# commonly - might require tweaks to your schema in the form of new tables, or new
+# columns on existing tables, or possibly the removal of tables or columns. Migrations
+# can even include arbitrary code to *transform* data as the underlying schema
+# changes.
+# 
+# The point is that at any particular stage in your application's development, 
+# migrations serve to transform the database into a state where it is compatible
+# and appropriate at that time.
+# 
+# == What about plugins?
+# 
+# If you want to share models using plugins, chances are that you might also
+# want to include the corresponding migrations to create tables for those models.
+# With the engines plugin installed, plugins can carry migration data easily:
+# 
+#   vendor/
+#     |
+#     plugins/
+#       |
+#       my_plugin/
+#         |- init.rb
+#         |- lib/
+#         |- db/
+#             |-migrate/
+#                 |- 001_do_something.rb
+#                 |- 002_and_something_else.rb
+#                 |- ...
+# 
+# When you install a plugin which contains migrations, you are undertaking a
+# further step in the development of your application, the same as the addition
+# of any other code. With this in mind, you may want to 'roll back' the
+# installation of this plugin at some point, and the database should be able
+# to migrate back to the point without this plugin in it too.
+#
+# == An example
+#
+# For example, our current application is at version 14 (according to the
+# +schema_info+ table), when we decide that we want to add a tagging plugin. The
+# tagging plugin chosen includes migrations to create the tables it requires
+# (say, _tags_ and _taggings_, for instance), along with the models and helpers
+# one might expect.
+#
+# After installing this plugin, these tables should be created in our database.
+# Rather than running the migrations directly from the plugin, they should be
+# integrated into our main migration stream in order to accurately reflect the
+# state of our application's database *at this moment in time*.
+#
+#   $ script/generate plugin_migration
+#         exists  db/migrate
+#         create  db/migrate/015_migrate_tagging_plugin_to_version_3.rb
+#
+# This migration will take our application to version 15, and contains the following, 
+# typical migration code:
+# 
+#   class MigrateTaggingPluginToVersion3 < ActiveRecord::Migration
+#     def self.up
+#       Engines.plugins[:tagging].migrate(3)
+#     end
+#     def self.down
+#       Engines.plugins[:tagging].migrate(0)
+#     end
+#   end
+#
+# When we migrate our application up, using <tt>rake db:migrate</tt> as normal,
+# the plugin will be migrated up to its latest version (3 in this example). If we
+# ever decide to migrate the application back to the state it was in at version 14,
+# the plugin migrations will be taken back down to version 0 (which, typically,
+# would remove all tables the plugin migrations define).
+#
+# == Upgrading plugins
+#
+# It might happen that later in an application's life, we update to a new version of
+# the tagging plugin which requires some changes to our database. The tagging plugin
+# provides these changes in the form of its own migrations. 
+#
+# In this case, we just need to re-run the plugin_migration generator to create a 
+# new migration from the current revision to the newest one:
+#
+#   $ script/generate plugin_migration
+#        exists db/migrate
+#        create db/migrate/023_migrate_tagging_plugin_to_version_5.rb
+#
+# The contents of this migration are:
+#
+#   class MigrateTaggingPluginToVersion3 < ActiveRecord::Migration
+#     def self.up
+#       Engines.plugins[:tagging].migrate(5)
+#     end
+#     def self.down
+#       Engines.plugins[:tagging].migrate(3)
+#     end
+#   end
+#
+# Notice that if we were to migrate down to revision 22 or lower, the tagging plugin
+# will be migrated back down to version 3 - the version we were previously at.
+#
+#
+# = Creating migrations in plugins
+#
+# In order to use the plugin migration functionality that engines provides, a plugin 
+# only needs to provide regular migrations in a <tt>db/migrate</tt> folder within it.
+#
+# = Explicitly migrating plugins
+#
+# It's possible to migrate plugins within your own migrations, or any other code.
+# Simply get the Plugin instance, and its Plugin#migrate method with the version
+# you wish to end up at:
+#
+#   Engines.plugins[:whatever].migrate(version)
+#
+# ---
+#
+# The Engines::RailsExtensions::Migrations module defines extensions for Rails' 
+# migration systems. Specifically:
+#
+# * Adding a hook to initialize_schema_information to create the plugin schema
+#   info table.
+#
+module Engines::RailsExtensions::Migrations
+  def self.included(base) # :nodoc:
+    base.class_eval { alias_method_chain :initialize_schema_information, :engine_additions }
+  end
+
+  # Create the schema tables, and ensure that the plugin schema table
+  # is also initialized. The plugin schema info table is defined by
+  # Engines::Plugin::Migrator.schema_info_table_name.
+  def initialize_schema_information_with_engine_additions
+    initialize_schema_information_without_engine_additions
+
+    # create the plugin schema stuff.    
+    begin
+      execute <<-ESQL
+        CREATE TABLE #{Engines::Plugin::Migrator.schema_info_table_name} 
+          (plugin_name #{type_to_sql(:string)}, version #{type_to_sql(:integer)})
+      ESQL
+    rescue ActiveRecord::StatementInvalid
+      # Schema has been initialized
+    end
+  end
+end
+
+module ::ActiveRecord #:nodoc:
+  module ConnectionAdapters #:nodoc:
+    module SchemaStatements #:nodoc:
+      include Engines::RailsExtensions::Migrations
+    end
+  end
+end
+
+# Set ActiveRecord to ignore the plugin schema table by default
+::ActiveRecord::SchemaDumper.ignore_tables << Engines.schema_info_table

data/starter-app/vendor/plugins/engines/lib/engines/rails_extensions/rails.rb

@@ -0,0 +1,11 @@
+# This is only here to allow for backwards compability with Engines that
+# have been implemented based on Engines for Rails 1.2. It is preferred that
+# the plugin list be accessed via Engines.plugins.
+
+module Rails
+  # Returns the Engines::Plugin::List from Engines.plugins. It is preferable to
+  # access Engines.plugins directly.
+  def self.plugins
+    Engines.plugins
+  end
+end

data/starter-app/vendor/plugins/engines/lib/engines/rails_extensions/routing.rb

@@ -0,0 +1,84 @@
+# Effective use of Rails' routes can help create a tidy and elegant set of URLs,
+# and is a significant part of creating an external API for your web application.
+# 
+# When developing plugins which contain controllers, it seems obvious that including
+# the corresponding routes would be extremely useful. This is particularly true
+# when exposing RESTful resources using the new REST-ian features of Rails.
+#
+# == Including routes in your plugin
+#
+# The engines plugin makes it possible to include a set of routes within your plugin
+# very simply, as it turns out. In your plugin, you simply include a <tt>routes.rb</tt> 
+# file like the one below at the root of your plugin:
+# 
+#   connect "/login", :controller => "my_plugin/account", :action => "login"
+#
+#   # add a named route
+#   logout "/logout", :controller => "my_plugin/account", :action => "logout"
+#
+#   # some restful stuff
+#   resources :things do |t|
+#     t.resources :other_things
+#   end
+# 
+# Everywhere in a normal <tt>RAILS_ROOT/config/routes.rb</tt> file 
+# where you might have <tt>map.connect</tt>, you just use <tt>connect</tt> in your 
+# plugin's <tt>routes.rb</tt>.
+# 
+# === Hooking it up in your application
+#
+# While it would be possible to have each plugin's routes automagically included into
+# the application's route set, to do so would actually be a stunningly bad idea. Route
+# priority is the key issue here. You, the application developer, needs to be in complete
+# control when it comes to specifying the priority of routes in your application, since 
+# the ordering of your routes directly affects how Rails will interpret incoming requests.
+# 
+# To add plugin routes into your application's <tt>routes.rb</tt> file, you need to explicitly 
+# map them in using the Engines::RailsExtensions::Routing#from_plugin method:
+# 
+#   ApplicationController::Routing::Routes.draw do |map|
+#
+#     map.connect "/app_stuff", :controller => "application_thing" # etc...
+#
+#     # This line includes the routes from the given plugin at this point, giving you
+#     # control over the priority of your application routes 
+#     map.from_plugin :your_plugin
+#
+#     map.connect ":controller/:action/:id"
+#   end
+# 
+# By including routes in plugins which have controllers, you can now share in a simple way 
+# a compact and elegant URL scheme which corresponds to those controllers.
+#
+# ---
+#
+# The Engines::RailsExtensions::Routing module defines extensions to Rails' 
+# routing (ActionController::Routing) mechanism such that routes can be loaded 
+# from a given plugin.
+#
+# The key method is Engines::RailsExtensions::Routing#from_plugin, which can be called 
+# within your application's <tt>config/routes.rb</tt> file to load plugin routes at that point.
+#
+module Engines::RailsExtensions::Routing
+  # Loads the set of routes from within a plugin and evaluates them at this
+  # point within an application's main <tt>routes.rb</tt> file.
+  #
+  # Plugin routes are loaded from <tt><plugin_root>/routes.rb</tt>.
+  def from_plugin(name)
+    map = self # to make 'map' available within the plugin route file
+    routes_path = Engines.plugins[name].routes_path
+    Engines.logger.debug "loading routes from #{routes_path}"
+    eval(IO.read(routes_path), binding, routes_path) if File.file?(routes_path)
+  end
+end
+
+  
+module ::ActionController #:nodoc:
+  module Routing #:nodoc:
+    class RouteSet #:nodoc:
+      class Mapper #:nodoc:
+        include Engines::RailsExtensions::Routing
+      end
+    end
+  end
+end

data/starter-app/vendor/plugins/engines/lib/engines/testing.rb

@@ -0,0 +1,87 @@
+# Contains the enhancements to assist in testing plugins. See Engines::Testing
+# for more details.
+
+require 'test/unit'
+
+require 'tmpdir'
+require 'fileutils'
+
+# In most cases, Rails' own plugin testing mechanisms are sufficient. However, there
+# are cases where plugins can be given a helping hand in the testing arena. This module 
+# contains some methods to assist when testing plugins that contain fixtures.
+# 
+# == Fixtures and plugins
+#
+# Since Rails' own fixtures method is fairly strict about where files can be loaded from,
+# the simplest approach when running plugin tests with fixtures is to simply copy all
+# fixtures into a single temporary location and inform the standard Rails mechanism to
+# use this directory, rather than RAILS_ROOT/test/fixtures.
+#
+# The Engines::Testing#setup_plugin_fixtures method does this, copying all plugin fixtures
+# into the temporary location before and tests are performed. This behaviour is invoked
+# the the rake tasks provided by the Engines plugin, in the "test:plugins" namespace. If
+# necessary, you can invoke the task manually.
+#
+# If you wish to take advantage of this, add a call to the Engines::Testing.set_fixture_path
+# method somewhere before your tests (in a test_helper file, or above the TestCase itself).
+#
+# = Testing plugins
+#
+# Normally testing a plugin will require that Rails is loaded, unless you are including
+# a skeleton Rails environment or set of mocks within your plugin tests. If you require
+# the Rails environment to be started, you must ensure that this actually happens; while
+# it's not obvious, your tests do not automatically run with Rails loaded.
+#
+# The simplest way to setup plugin tests is to include a test helper with the following
+# contents:
+#
+#   # Load the normal Rails helper. This ensures the environment is loaded
+#   require File.expand_path(File.dirname(__FILE__) + '/../../../../test/test_helper')
+#   # Ensure that we are using the temporary fixture path
+#   Engines::Testing.set_fixture_path
+#
+# Then run tests using the provided tasks (<tt>test:plugins</tt>, or the tasks that the engines
+# plugin provides - <tt>test:plugins:units</tt>, etc.).
+#
+# Alternatively, you can explicitly load the environment by adpating the contents of the
+# default <tt>test_helper</tt>:
+#
+#   ENV["RAILS_ENV"] = "test"
+#   # Note that we are requiring config/environment from the root of the enclosing application.
+#   require File.expand_path(File.dirname(__FILE__) + "/../../../../config/environment")
+#   require 'test_help'
+#
+module Engines::Testing
+  mattr_accessor :temporary_fixtures_directory
+  self.temporary_fixtures_directory = FileUtils.mkdir_p(File.join(Dir.tmpdir, "rails_fixtures"))
+  
+  # Copies fixtures from plugins and the application into a temporary directory 
+  # (Engines::Testing.temporary_fixtures_directory). 
+  # 
+  # If a set of plugins is not given, fixtures are copied from all plugins in order 
+  # of precedence, meaning that plugins can 'overwrite' the fixtures of others if they are 
+  # loaded later; the application's fixtures are copied last, allowing any custom fixtures
+  # to override those in the plugins. If no argument is given, plugins are loaded via
+  # PluginList#by_precedence.
+  #
+  # This method is called by the engines-supplied plugin testing rake tasks
+  def self.setup_plugin_fixtures(plugins = Engines.plugins.by_precedence)
+    
+    # Copy all plugin fixtures, and then the application fixtures, into this directory
+    plugins.each do |plugin| 
+      plugin_fixtures_directory =  File.join(plugin.directory, "test", "fixtures")
+      if File.directory?(plugin_fixtures_directory)
+        Engines.mirror_files_from(plugin_fixtures_directory, self.temporary_fixtures_directory)
+      end
+    end
+    Engines.mirror_files_from(File.join(RAILS_ROOT, "test", "fixtures"),
+                              self.temporary_fixtures_directory)
+  end
+  
+  # Sets the fixture path used by Test::Unit::TestCase to the temporary
+  # directory which contains all plugin fixtures.
+  def self.set_fixture_path
+    Test::Unit::TestCase.fixture_path = self.temporary_fixtures_directory
+    $LOAD_PATH.unshift self.temporary_fixtures_directory
+  end
+end