NAME
MooseX::Object::Pluggable - Make your classes pluggable
SYNOPSIS
package MyApp;
use Moose;
with 'MooseX::Object::Pluggable';
...
package MyApp::Plugin::Pretty;
use Moose::Role;
sub pretty{ print "I am pretty" }
1;
#
use MyApp;
my $app = MyApp->new;
$app->load_plugin('Pretty');
$app->pretty;
DESCRIPTION
This module is meant to be loaded as a role from Moose-based classes it will add five methods and five attributes to assist you with the loading and handling of plugins and extensions for plugins. I understand that this may pollute your namespace, however I took great care in using the least ambiguous names possible.
How plugins Work
Plugins and extensions are just Roles by a fancy name. They are loaded at runtime on demand and are instance, not class based. This means that if you have more than one instance of a class they can all have different plugins loaded. This is a feature.
Plugin methods are allowed to around
, before
, after
their consuming classes, so it is important to watch for load order as plugins can and will overload each other. You may also add attributes through has.
Even thouch override
will work in basic cases, I STRONGLY discourage it's use and a warning will be thrown if you try to use it. This is closely linked to the way multiple roles being applies is handles and is not likely to change. override
bevavior is closely linked to inheritance and thus will likely not work as you expect it in multiple inheritance situations. Point being, save yourself the headache.
How plugins are loaded
You don't really need to understand anything except for the first paragraph.
The first time you load a plugin a new anonymous Moose::Meta::Class will be created. This class will inherit from your pluggable object and then your object will be reblessed to an instance of this anonymous class. This means that $self->blessed
and ref $self
will no longer return the name of your object, they will instead return the name of the anonymous class created at runtime. Your original class name can be located at ($self->meta->superclasses)[0]
Once the anonymous subclass exists all plugin roles will be apply
ed to this class directly. This "subclass" though is in fact now $self
and it isa($yourclassname)
. If this is confusing.. it should be, thats why you let me handle it. Just know that it has to be done this way in order for plugins to override core functionality.
For a simple example see the tests for this distribution.
Attributes
_plugin_ns
String. The prefix to use for plugin names provided. MyApp::Plugin is sensible.
_plugin_ext
Boolean. Indicates whether we should attempt to load plugin extensions. Defaults to true;
_plugin_ext_ns
String. The namespace plugin extensions have. Defaults to 'ExtensionFor'.
This means that is _plugin_ns is "MyApp::Plugin" and _plugin_ext_ns is "ExtensionFor" loading plugin "Bar" would search for extensions in "MyApp::Plugin::Bar::ExtensionFor::*".
_plugin_loaded
HashRef. Keeps an inventory of what plugins are loaded and what the actual module name is to avoid multiple loading.
__plugin_subclass
Object. This holds the subclass of our pluggable object in the form of an anonymous Moose::Meta::Class instance. All roles are actually applied to this instance instead of the original class instance in order to not lose the original object name as roles are applied. The anonymous class will be automatically generated upon first use.
Public Methods
load_plugin $plugin
This is the only method you should be using. Load the apropriate role for $plugin
as well as any extensions it provides if extensions are enabled.
_load_plugin_ext
Will load any extensions for a particular plugin. This should be called automatically by load_plugin
so you don't need to worry about it. It basically attempts to load any extension that exists for a plugin that is already loaded. The only reason for using this is if you want to keep _plugin_ext as false and only load extensions manually, which I don't recommend.
Private Methods
There's nothing stopping you from using these, but if you are using them you are probably doing something wrong.
_plugin_subclass
Creates, if needed and returns the anonymous instance of the consuming objects subclass to which roles will be applied to.
_role_from_plugin $plugin
Creates a role name from a plugin name. If the plugin name is prepended with a +
it will be treated as a full name returned as is. Otherwise a string consisting of $plugin
prepended with the application name and _plugin_ns
will be returned. Example
#assuming appname MyApp and C<_plugin_ns> 'Plugin'
$self->_role_from_plugin("MyPlugin"); # MyApp::Plugin::MyPlugin
_load_and_apply_role $role
Require $role
if it is not already loaded and apply it to _plugin_subclass
. This is the meat of this module.
SEE ALSO
AUTHOR
Guillermo Roditi, <groditi@cpan.org>
BUGS
Holler?
Please report any bugs or feature requests to bug-moosex-object-pluggable at rt.cpan.org
, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=MooseX-Object-Pluggable. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.
SUPPORT
You can find documentation for this module with the perldoc command.
perldoc MooseX-Object-Pluggable
You can also look for information at:
AnnoCPAN: Annotated CPAN documentation
CPAN Ratings
RT: CPAN's request tracker
http://rt.cpan.org/NoAuth/Bugs.html?Dist=MooseX-Object-Pluggable
Search CPAN
ACKNOWLEDGEMENTS
- #Moose - Huge number of questions
- Matt S Trout <mst@shadowcatsystems.co.uk> - ideas / planning.
- Stevan Little - EVERYTHING. Without him this would have never happened.
COPYRIGHT
Copyright 2007 Guillermo Roditi. All Rights Reserved. This is free software; you may redistribute it and/or modify it under the same terms as Perl itself.