Acme-CPANModules-PERLANCAR-PluginSystem
view release on metacpan or search on metacpan
lib/Acme/CPANModules/PERLANCAR/PluginSystem.pm view on Meta::CPAN
_
entries => [
{
module => 'Plugin::System',
description => <<'_',
The current name of what the plugin system will be refactored into.
_
},
{
module => "ScriptX",
description => <<'_',
Started in late 2019, this is the first framework where the I thought out the
rough feature set that I want. ScriptX was written to eventually replace
<pm:Perinci::CmdLine>: I want a framework that can be used to write web
scripts/form handlers as well as CLI scripts, with more flexibility in composing
behavior/functionality (i.e. plugin-based). But turns out I haven't had enough
time to hack on it, and making CLI scripts are 99% of what I use Perl for; thus
Perinci::CmdLine lives on for now (with plugins since 1.900).
_
},
{
module => "Perinci::CmdLine::Lite",
description => <<'_',
While waiting for <pm:ScriptX> to get into a usable form, I implemented a
similar system to my CLI framework, <pm:Perinci::CmdLine> starting from 1.900
(released in Oct 2020).
_
},
{
module => "Require::HookPlugin",
description => <<'_',
Another project where I implemented the same plugin system to a require hook
framework. Require::HookPlugin (RHP) was started in July 2023 because I found
hook ordering in <pm:Require::HookChain> (RHC) to be fragile and error-prone.
Plus, I want more customizability and composability than what RHC provides.
_
},
],
};
1;
# ABSTRACT: List of my modules/frameworks which use a particular plugin system style
__END__
=pod
=encoding UTF-8
=head1 NAME
Acme::CPANModules::PERLANCAR::PluginSystem - List of my modules/frameworks which use a particular plugin system style
=head1 VERSION
This document describes version 0.002 of Acme::CPANModules::PERLANCAR::PluginSystem (from Perl distribution Acme-CPANModules-PERLANCAR-PluginSystem), released on 2023-07-23.
=head1 DESCRIPTION
This is a personal list of my modules/frameworks which use a particular plugin
system style which I will someday extract into its own framework
(L<Plugin::System>). (And I am also slowly converting more of my
plugin-supporting projects to use this style). Some of the features of this
particular plugin style:
=over
=item * a plugin can be installed more than once and parameterized (like in L<Dist::Zilla> or L<Pod::Weaver>) [flexibility];
=item * execution order of plugins is by priority, then by its order of activation;
=item * a plugin has a default priority value but the value can be overriden by user [flexibility];
=item * a plugin has a default event in which it participates, but user can overrides this [flexibility];
=item * support for repeating an event [flexibility];
=item * support for skipping (aborting) an event [flexibility];
=back
=head1 ACME::CPANMODULES ENTRIES
=over
=item L<Plugin::System>
The current name of what the plugin system will be refactored into.
=item L<ScriptX>
Author: L<PERLANCAR|https://metacpan.org/author/PERLANCAR>
Started in late 2019, this is the first framework where the I thought out the
rough feature set that I want. ScriptX was written to eventually replace
L<Perinci::CmdLine>: I want a framework that can be used to write web
scripts/form handlers as well as CLI scripts, with more flexibility in composing
behavior/functionality (i.e. plugin-based). But turns out I haven't had enough
time to hack on it, and making CLI scripts are 99% of what I use Perl for; thus
Perinci::CmdLine lives on for now (with plugins since 1.900).
=item L<Perinci::CmdLine::Lite>
Author: L<PERLANCAR|https://metacpan.org/author/PERLANCAR>
While waiting for L<ScriptX> to get into a usable form, I implemented a
( run in 2.365 seconds using v1.01-cache-2.11-cpan-39bf76dae61 )