in reply to Plugin-type architecture

Well, there are many ways you can go with this, so I will give you some ideas that you can combine to meet your own needs.

It is probably a good idea to design an interface that all of your plugins must implement. That way, when you do discover what plugins are installed, you can instantiate and work with them.

You will probably identify a plugin directory. You can easily get a list of .pm files in the directory:

my @plugins = <plugins/*.pm>;

[download]

or even use File::Find to recursivly search.

When you have a file you can work with it as such:

for (@plugins) {
   require $_;  # Basically "use"-ing the file
   s/\//::/g;   # Convert the path name into a package name
   s/\.pm$//;
   push @pluginInstances, $_->new; # Create a new instance
}

[download]

So, using file listing features, require (or do or eval), you can list and load your plugins. How you track your plugins within the app and how your plugins integrate will be entirely up to your needs.

Ted Young

($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)

Replies are listed 'Best First'.
Re^2: Plugin-type architecture
by philcrow (Priest) on Jan 10, 2006 at 18:43 UTC
    You could also simply let the user specify which plugins they want at compile or run time, instead of loading them all at once. For instance, you could have your caller's say 
    use YourModule qw( List Of Plugins );

    [download]
    Then in YourModule have an import like this: 
    use File::Spec;
sub import {
    my $class = shift;
    
    foreach my $plugin ( @_ ) {
        my $fullname = File::Spec::catfile(
            $class,
            'Plugin',
            "$plugin.pm"
        );
        require $fullname;
    }
}

    [download]
    This assumes that your plugins are really called YourModule::Plugin::Name and that they don't go deeper (so YourModule::Plugin::TopLevel::Name won't work). But you could change the way the name is formed to take care of that.

    Phil

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom