CatalystX::Features - Merges different application directories into your app.


version 0.26


        package MyApp;
        use Catalyst qw/-Debug


The idea behind this module is to make it easier to spread your code outside of the main application directory, in the spirit of Eclipse features and Ruby on Rails plugins.

It's mainly useful if you're working on a large application with distinct isolated features that are not tightly coupled with the main app and could be pulled off or eventually reused somewhere else.

It also comes handy in a large project, with many developers working on specific application parts. And, say, you wish to split the functionality in diretories, or just want to keep them out of the application core files.


  • Create a directory under your app home named /features

            mkdir /MyApp/features/
  • Each feature home dir should be named something like:


It's a split on underscore _, the first part is the feature name, the second is the feature version.

Also splits on a dash -, allowing the feature to be named as Feature-0.9123.

If a higher version of a feature is found, that's the one to be used, the rest is ignored

  • a feature without a version is ok, it will be the highest version available - good for local dev and pushing to a repository.

  • a debug box is printed on startup, so you can check which version is running:

            [debug] Features Loaded:
            | Home                                   | Name                   | Version  |
            | simple.feature_1.0.0                   | simple.feature         | 1.0.0    |

Disabling features

If you need a feature to be ignored, append a hash # sign in front of the directory name:





That way the feature folder will be ignored during the initialization phase.

You can also disable by setting the $CatalystX::Features::DISABLED variable early in your code:

    use Catalyst::Runtime 5.70;

    BEGIN {
        $CatalystX::Features::DISABLED = [ qw/simple.feature anotherone/ ];
    # ...



Let's you set a list of directories where your features are located. It expects full paths.

                home /opt/myapp_features
                home /somewhere/else

Defaults to:



Sets an alternative class to use as a backend. The default is CatalystX::Features::Backend.

                backend_class MyApp::Features


Sets an alternative class to represent a single feature. The default is CatalystX::Features::Feature. This class should implement the role CatalystX::Features::Role::Feature.

                feature_class MyApp::Feature



The plugin setup method. Loads features and prints the feature configuration table.


Returns the feature backend object.


Returns an array of loaded features, which are instances of the CatalystX::Features::Feature class.


Does the dirty setup work. Called from various CatalystX::Features::Plugin::* to make sure features are loaded.


A rewrite of Catalyst's path_to method, so that it will search for the file path within features.

If your feature has the following file:


You may get the path to it using path_to as usual from within your feature:

        my $path = $c->path_to( 'root', 'file.ext' );   

This will work from any feature or from the main app, but it does not allow a file in one feature to get a path to a file in another.


These things here, and many, many more that I can't recall right now.

  • Check splicit dependencies among features (although Perl's implicit dependency checking is perfectly valid).

  • Be able to run complete tests.

  • More plugins: TT::Alloy, Email::Template, etc.

  • Deploy PAR/ZIP files automatically.

  • Delayed initialization into INC


        Rodrigo de Oliveira (rodrigolive), C<>


    Robert Buels (rbuels), C<>


This library is free software. You can redistribute it and/or modify it under the same terms as Perl itself.