Mojolicious-Plugin-Fondation

 view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

hierarchical, recursive plugin loading with automatic configuration
merging, resource sharing (controllers, templates), and post-load actions.

It is designed for modular applications where multiple plugins contribute
routes, templates, and behavior, while avoiding duplicate loads and
respecting configuration priorities.

Key features:

- Recursive plugin loading via `dependencies`
- Configuration cascade: direct > app config > plugin defaults
- Automatic discovery and registration of `share/templates`
- Application-level `share/templates` have priority
- Extensible post-load actions (Templates, Controllers, custom)
- Deferred initialization via `fondation_finalyze`
- Contextual logging via `$self->log` (Mojo::Log context)

# LOADING ORDER

    1. load_plugin_recursive
       └─ Fondation -> dependencies recursively

README.md  view on Meta::CPAN

        },
    }

    # myapp.pl
    plugin 'Config';
    plugin 'Fondation';   # reads dependencies from config

# CONFIGURATION PRIORITIES

Each plugin receives a merged configuration built from three sources,
combined with [Hash::Merge](https://metacpan.org/pod/Hash%3A%3AMerge). The cascade priority is:

### 1. Direct configuration (passed in `dependencies` array)

    plugin 'Fondation' => {
        dependencies => [
            { 'Fondation::User' => { title => 'Direct override' } },
        ],
    };

### 2. Application configuration file (e.g. myapp.conf)

lib/Mojolicious/Plugin/Fondation.pm  view on Meta::CPAN

It is designed for modular applications where multiple plugins contribute
routes, templates, and behavior, while avoiding duplicate loads and
respecting configuration priorities.

Key features:

=over 4

=item * Recursive plugin loading via C<dependencies>

=item * Configuration cascade: direct > app config > plugin defaults

=item * Automatic discovery and registration of C<share/templates>

=item * Application-level C<share/templates> have priority

=item * Extensible post-load actions (Templates, Controllers, custom)

=item * Deferred initialization via C<fondation_finalyze>

=item * Contextual logging via C<< $self->log >> (Mojo::Log context)

lib/Mojolicious/Plugin/Fondation.pm  view on Meta::CPAN

        },
    }

    # myapp.pl
    plugin 'Config';
    plugin 'Fondation';   # reads dependencies from config

=head1 CONFIGURATION PRIORITIES

Each plugin receives a merged configuration built from three sources,
combined with L<Hash::Merge>. The cascade priority is:

=head3 1. Direct configuration (passed in C<dependencies> array)

    plugin 'Fondation' => {
        dependencies => [
            { 'Fondation::User' => { title => 'Direct override' } },
        ],
    };

=head3 2. Application configuration file (e.g. myapp.conf)

lib/Mojolicious/Plugin/Fondation/Command/fondation.pm  view on Meta::CPAN

          defaults => {
              fondation_init    => [ ['db', 'prepare', '-y'], ['db', 'install'] ],
              fondation_upgrade => [ ['db', 'prepare', '-y', '-a'], ['db', 'upgrade'] ],
              fondation_clean   => ['data/app.db'],
          },
      };
  }

All three keys are optional -- a plugin only declares what it needs.
Because they live in C<defaults>, they participate in the config merge
cascade (direct > app config > defaults). Users can override or extend
them just like any other Fondation config value.

=over

=item * C<fondation_init> -- array of command steps, each C<[command, args...]>

=item * C<fondation_upgrade> -- array of command steps for incremental upgrade

=item * C<fondation_clean> -- array of paths (relative to app home) to remove