[Jifty-commit] jifty branch, config-extensions, created. 1.10518-62-g7753e31

[Jifty commits]

The branch, config-extensions has been created
        at  7753e3131acdc04f73a225e2f10823126f1bff4d (commit)

- Log -----------------------------------------------------------------
commit c4167614f8c6b6c915d680fae4e198ff43c0674f
Author: Alex Vandiver <alexmv at bestpractical.com>
Date:   Sat Dec 3 16:54:55 2011 -0500

    Allow a mechanism to force-set certain values, ignoring merging rules

diff --git a/lib/Jifty/Config.pm b/lib/Jifty/Config.pm
index 2d3c8a2..0011a80 100644
--- a/lib/Jifty/Config.pm
+++ b/lib/Jifty/Config.pm
@@ -315,10 +315,26 @@ sub merge {
     my ($new, $fallback) = @_;
     $fallback ||= $self->stash;
 
+    # These are now more correctly done with the ! syntax, below, rather
+    # than these special-cases.
     delete $fallback->{framework}{MailerArgs} if exists $new->{framework}{MailerArgs};
     delete $fallback->{framework}{View}{Handlers} if exists $new->{framework}{View}{Handlers};
 
-    $self->stash(Hash::Merge::merge( $fallback, $new ));
+    my $unbang;
+    $unbang = sub {
+        my $ref = shift;
+        if (ref $ref eq "HASH") {
+            $ref->{$_} = delete $ref->{$_ . "!"}
+                for map {s/!$//; $_} grep {/!$/} keys %{$ref};
+            $ref->{$_} = $unbang->( $ref->{$_} )
+                for keys %{$ref};
+        } elsif (ref $ref eq "ARRAY") {
+            $ref = [ map { $unbang->($_) } @{$ref} ];
+        }
+        return $ref;
+    };
+
+    $self->stash( $unbang->( Hash::Merge::merge( $fallback, $new ) ) );
 }
 
 # Sets up the initial location of the site configuration file
@@ -703,6 +719,19 @@ This provides an additional layer of abstraction for truly complicated deploymen
 
 The site configuration allows for specific overrides of the application and vendor configuration. For example, a particular Jifty application might define all the application defaults in the application configuration file. Then, each administrator that has downloaded that application and is installing it locally might customize the configuration for a particular deployment using this configuration file, while leaving the application defaults intact (and, thus, still available for later reference). This can even override the vendor file containing a standard set of overrides.
 
+=head1 MERGING RULES
+
+Values from files loaded later take precedence; that is, Jifty's
+defaults are overridden by the application configuration file, then the
+vendor configuration file, then the site configuration file.  At each
+step, the new values are merged into the old values using
+L<Hash::Merge>.  Specifically, arrays which exist in both old and new
+data structures are appended, and hashes are merged.
+
+One special rule applies, however: if a key in a hash ends in C<!>, the
+it simply overrides the equivalent non-C<!> key's value, ignoring normal
+merging rules.
+
 =head1 SEE ALSO
 
 L<Jifty>

commit 2ab469a3eeee8dd5faa419c419479d847493b58b
Author: Alex Vandiver <alexmv at bestpractical.com>
Date:   Sat Dec 3 16:56:01 2011 -0500

    Allow a site_config.yml to override config.yml's plugin configuration, based on plugin class name

diff --git a/lib/Jifty/Config.pm b/lib/Jifty/Config.pm
index 0011a80..f424a20 100644
--- a/lib/Jifty/Config.pm
+++ b/lib/Jifty/Config.pm
@@ -320,6 +320,32 @@ sub merge {
     delete $fallback->{framework}{MailerArgs} if exists $new->{framework}{MailerArgs};
     delete $fallback->{framework}{View}{Handlers} if exists $new->{framework}{View}{Handlers};
 
+    # Plugins _need_ some special-case magic to get merged, as they're
+    # not just a hashref of classname to config, but an arrayref of
+    # one-key hashrefs to config, where the key is the classname.  This
+    # is so there is an ordering between plugins.
+    #
+    # Grab all of the existant plugin config refs, and key them by classname.
+    my %plugins;
+    for my $p (@{$fallback->{framework}{Plugins} || []}) {
+        my ($class) = keys %{$p};
+        # It's _possible_ that a single config source defined a plugin
+        # multiple times; the || sets us up to merge into only the first
+        # one.
+        $plugins{$class} ||= $p->{$class};
+    }
+    # Now iterate through all of the new ones, peelling off and merging
+    # new data into the old ref, or pushing the new ref into the old
+    # plugin list.
+    for my $p (@{delete $new->{framework}{Plugins} || []}) {
+        my ($class) = keys %{$p};
+        if ($plugins{$class}) {
+            %{$plugins{$class}} = (%{$plugins{$class}}, %{$p->{$class}});
+        } else {
+            push @{$fallback->{framework}{Plugins}}, $p;
+        }
+    }
+
     my $unbang;
     $unbang = sub {
         my $ref = shift;
@@ -728,9 +754,30 @@ step, the new values are merged into the old values using
 L<Hash::Merge>.  Specifically, arrays which exist in both old and new
 data structures are appended, and hashes are merged.
 
-One special rule applies, however: if a key in a hash ends in C<!>, the
-it simply overrides the equivalent non-C<!> key's value, ignoring normal
-merging rules.
+Some special rules apply, however:
+
+=over
+
+=item *
+
+If a key in a hash ends in C<!>, the normal merging rules do not apply;
+it simply overrides the equivalent non-C<!> key's value.
+
+=item *
+
+Plugins from one file are merged into the plugin configuration from
+previous files if their plugin classes match.  That is, if both
+F<config.yml> and F<site_config.yml> define a
+L<Jifty::Plugin::CompressedCSSandJS>, rather than causing _two_ such
+plugins to be instantiated, the F<site_config.yml>'s plugin
+configuration keys will override those of F<config.yml>.
+
+This rule is only special because the C<Plugins> key in Jifty's config
+is an arrayref, not a hashref on plugin class name, to allow for both
+template and dispatcher ordering, as well as the possibility of repeated
+plugins.
+
+=back
 
 =head1 SEE ALSO
 

commit 7753e3131acdc04f73a225e2f10823126f1bff4d
Author: Alex Vandiver <alexmv at bestpractical.com>
Date:   Sat Dec 3 16:56:21 2011 -0500

    Fix pod header sizes

diff --git a/lib/Jifty/Config.pm b/lib/Jifty/Config.pm
index f424a20..237c07f 100644
--- a/lib/Jifty/Config.pm
+++ b/lib/Jifty/Config.pm
@@ -729,13 +729,13 @@ The Jifty configuration can be loaded from many locations. This breakdown allows
 
 This section hopes to explain the intended purpose of each configuration file.
 
-=head1 APPLICATION
+=head2 APPLICATION
 
 The first configuration file loaded is the application configuration. This file provides the basis for the rest of the configuration loaded. The purpose of this file is for storing the primary application-specific configuration and defaults.
 
 This can be used as the sole configuration file on a simple deployment. In a complex environment, however, this file may be considered read-only to be overridden by other files, allowing the later files to customize the configuration at each level.
 
-=head1 VENDOR
+=head2 VENDOR
 
 The vendor configuration file is loaded and overrides settings in the application configuration. This is an intermediate level in the configuration. It overrides any defaults specified in the application configuration, but is itself overridden by the site configuration.
 

-----------------------------------------------------------------------