parlement 0.14 → 0.17

data/vendor/plugins/engines/lib/engines/rails_extensions/active_record.rb

@@ -1,19 +0,0 @@
-# Here we add a single helpful method to ActiveRecord::Base. This method may be deprecated
-# in the future, since support for the Module#config mechanism which required it has
-# also been dropped.
-module Engines::RailsExtensions::ActiveRecord
-  # NOTE: Currently the Migrations system will ALWAYS wrap given table names
-  # in the prefix/suffix, so any table name set via ActiveRecord::Base#set_table_name, 
-  # for instance will always get wrapped in the process of migration. For this 
-  # reason, whatever value you give to the config will be wrapped when set_table_name 
-  # is used in the model.
-  #
-  # This method is useful for determining the actual name (including prefix and 
-  # suffix) that Rails will use for a model, given a particular set_table_name
-  # parameter.
-  def wrapped_table_name(name)
-    table_name_prefix + name + table_name_suffix
-  end
-end
-
-::ActiveRecord::Base.extend(Engines::RailsExtensions::ActiveRecord)

data/vendor/plugins/engines/lib/engines/rails_extensions/dependencies.rb

@@ -1,143 +0,0 @@
-# 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.
-    ['controller', 'helper'].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
-        Rails.plugins.each do |plugin|
-          plugin_file_name = File.expand_path(File.join(plugin.root, 'app', "#{file_type}s", base_name))
-          logger.debug("checking plugin '#{plugin.name}' for '#{base_name}'")
-          if File.file?("#{plugin_file_name}.rb")
-            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
-          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")
-            logger.debug("loading from application: #{base_name}")
-            file_loaded = true if require_or_load_without_engine_additions(app_file_name, const_path)
-          else
-            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
-
-::Dependencies.send(:include, Engines::RailsExtensions::Dependencies)

data/vendor/plugins/engines/lib/engines/rails_extensions/migrations.rb

@@ -1,155 +0,0 @@
-# Contains the enhancements to Rails' migrations system to support the 
-# Engines::PluginMigrator. 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
-#       Rails.plugins[:tagging].migrate(3)
-#     end
-#     def self.down
-#       Rails.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
-#       Rails.plugins[:tagging].migrate(5)
-#     end
-#     def self.down
-#       Rails.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:
-#
-#   Rails.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::PluginMigrator.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::PluginMigrator.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
-
-::ActiveRecord::ConnectionAdapters::SchemaStatements.send(:include, Engines::RailsExtensions::Migrations)
-
-# Set ActiveRecord to ignore the plugin schema table by default
-::ActiveRecord::SchemaDumper.ignore_tables << Engines.schema_info_table

data/vendor/plugins/engines/lib/engines/rails_extensions/public_asset_helpers.rb

@@ -1,116 +0,0 @@
-# The engines plugin makes it trivial to share public assets using plugins. 
-# To do this, include an <tt>assets</tt> directory within your plugin, and put
-# your javascripts, stylesheets and images in subdirectories of that folder:
-#
-#   my_plugin
-#     |- init.rb
-#     |- lib/
-#     |- assets/
-#          |- javascripts/
-#          |    |- my_functions.js
-#          |
-#          |- stylesheets/
-#          |    |- my_styles.css
-#          |
-#          |- images/
-#               |- my_face.jpg
-#
-# Files within the <tt>asset</tt> structure are automatically mirrored into
-# a publicly-accessible folder each time your application starts (see
-# Plugin#mirror_public_assets).
-#
-#
-# == Using plugin assets in views
-#
-# It's also simple to use Rails' helpers in your views to use plugin assets.
-# The default helper methods have been enhanced by the engines plugin to accept
-# a <tt>:plugin</tt> option, indicating the plugin containing the desired asset.
-#
-# For example, it's easy to use plugin assets in your layouts:
-#
-#   <%= stylesheet_link_tag "my_styles", :plugin => "my_plugin", :media => "screen" %>
-#   <%= javascript_include_tag "my_functions", :plugin => "my_plugin" %>
-# 
-# ... and similarly in views and partials, it's easy to use plugin images:
-#
-#   <%= image_tag "my_face", :plugin => "my_plugin" %>
-#   <!-- or -->
-#   <%= image_path "my_face", :plugin => "my_plugin" %>
-#
-# Where the default helpers allow the specification of more than one file (i.e. the
-# javascript and stylesheet helpers), you can do similarly for multiple assets from 
-# within a single plugin.
-#
-# ---
-#
-# This module enhances four of the methods from ActionView::Helpers::AssetTagHelper:
-#
-#  * stylesheet_link_tag
-#  * javascript_include_tag
-#  * image_path
-#  * image_tag
-#
-# Each one of these methods now accepts the key/value pair <tt>:plugin => "plugin_name"</tt>,
-# which can be used to specify the originating plugin for any assets.
-#
-module Engines::RailsExtensions::PublicAssetHelpers
-  def self.included(base) #:nodoc:
-    base.class_eval do
-      [:stylesheet_link_tag, :javascript_include_tag, :image_path, :image_tag].each do |m|
-        alias_method_chain m, :engine_additions
-      end
-    end
-  end
-  
-  # Adds plugin functionality to Rails' default stylesheet_link_tag method.
-  def stylesheet_link_tag_with_engine_additions(*sources)
-    stylesheet_link_tag_without_engine_additions(*Engines::RailsExtensions::PublicAssetHelpers.pluginify_sources("stylesheets", *sources))
-  end
-
-  # Adds plugin functionality to Rails' default javascript_include_tag method.  
-  def javascript_include_tag_with_engine_additions(*sources)
-    javascript_include_tag_without_engine_additions(*Engines::RailsExtensions::PublicAssetHelpers.pluginify_sources("javascripts", *sources))
-  end
-  
-  #--
-  # Our modified image_path now takes a 'plugin' option, though it doesn't require it
-  #++
-  
-  # Adds plugin functionality to Rails' default image_path method.
-  def image_path_with_engine_additions(source, options={})
-    options.stringify_keys!
-    source = Engines::RailsExtensions::PublicAssetHelpers.plugin_asset_path(options["plugin"], "images", source) if options["plugin"]
-    image_path_without_engine_additions(source)
-  end
-  
-  # Adds plugin functionality to Rails' default image_tag method.
-  def image_tag_with_engine_additions(source, options={})
-    options.stringify_keys!
-    if options["plugin"]
-      source = Engines::RailsExtensions::PublicAssetHelpers.plugin_asset_path(options["plugin"], "images", source)
-      options.delete("plugin")
-    end
-    image_tag_without_engine_additions(source, options)
-  end
-  
-  #--
-  # The following are methods on this module directly because of the weird-freaky way
-  # Rails creates the helper instance that views actually get
-  #++
-  
-  # Convert sources to the paths for the given plugin, if any plugin option is given
-  def self.pluginify_sources(type, *sources)
-    options = sources.last.is_a?(Hash) ? sources.pop.stringify_keys : { }
-    sources.map! { |s| plugin_asset_path(options["plugin"], type, s) } if options["plugin"]
-    options.delete("plugin") # we don't want it appearing in the HTML
-    sources << options # re-add options      
-  end  
-
-  # Returns the publicly-addressable relative URI for the given asset, type and plugin
-  def self.plugin_asset_path(plugin_name, type, asset)
-    raise "No plugin called '#{plugin_name}' - please use the full name of a loaded plugin." if Rails.plugins[plugin_name].nil?
-    "/#{Rails.plugins[plugin_name].public_asset_directory}/#{type}/#{asset}"
-  end
-end
-
-::ActionView::Helpers::AssetTagHelper.send(:include, Engines::RailsExtensions::PublicAssetHelpers)

data/vendor/plugins/engines/lib/engines/rails_extensions/rails.rb

@@ -1,20 +0,0 @@
-# In order to give a richer infrastructure for dealing with plugins, the engines
-# plugin adds two new attributes to the Rails module:
-#
-# [+plugins+]       A PluginList instance which holds the currently loaded plugins
-# [+configuration+] The current Rails::Configuration instance, so that we can
-#                   query any parameters that might be set *after* Rails has
-#                   loaded, as well as during plugin initialization
-#
-#--
-# Here we just re-open the Rails module and add our custom accessors; it
-# may be cleaner to seperate them into a module, but in this case that seems
-# like overkill.
-#++
-module Rails
-  # The set of all loaded plugins
-  mattr_accessor :plugins
-  
-  # The Rails::Initializer::Configuration object
-  mattr_accessor :configuration
-end