CLI::Framework::Application - Build standardized, flexible, testable command-line applications
#---- CLIF Application class -- lib/My/Journal.pm
package My::Journal;
use base qw( CLI::Framework::Application );
sub init {
my ($self, $opts) = @_;
# ...connect to DB, getting DB handle $dbh...
$self->session('dbh' => $dbh); # (store $dbh in shared session slot)
}
1;
#---- CLIF Command class -- lib/My/Journal/Command/Entry.pm
package My::Journal::Command::Entry;
use base qw( CLI::Framework::Command );
sub run { ... }
1;
#---- CLIF (sub)Command Class -- can be defined inline in master command
# package file for My::Journal::Command::Entry or in dedicated package
# file lib/My/Journal/Command/Entry/Add.pm
package My::Journal::Command::Entry::Add;
use base qw( My::Journal::Command::Entry );
sub run { ... }
1;
#---- ...<more similar class definitions for 'entry' subcommands>...
#---- CLIF Command Class -- lib/My/Journal/Command/Publish.pm
package My::Journal::Command::Publish;
use base qw( CLI::Framework::Command );
sub run { ... }
1;
#---- CLIF executable script: journal
use My::Journal;
My::Journal->run();
#---- Command-line
$ journal entry add 'today I wrote some POD'
$ journal entry search --regex='perl'
$ journal entry print 1 2 3
$ journal publish --format=pdf --template=my-journal --out=~/notes/journal-20090314.txt
CLI::Framework (nickname "CLIF") provides a framework and conceptual pattern for building full-featured command line applications. It intends to make this process easy and consistent. It assumes responsibility for common details that are application-independent, making it possible for new CLI applications to be built without concern for these recurring aspects (which are otherwise very tedious to implement).
For instance, the Journal application example in the SYNOPSIS is an example of a CLIF application for a personal journal. The application has both commands and subcommands. Since the application class, My::Journal, is a subclass of CLI::Framework::Application, the Journal application is free to focus on implementation of its individual commands with minimum concern for the many details involved in building an interface around those commands. The application is composed of concise, understandable code in packages that are easy to test and maintain. This methodology for building CLI apps can be adopted as a standardized convention.
"Quickstart" and "Tutorial" guides are currently being prepared for the next CLIF release. However, this early version has the necessary content. See especially CLI::Framework::Application and CLI::Framework::Command. Also, there are example CLIF applications (demonstrating both simple and advanced usage) included with the tests for this distribution.
There are a few other distributions on CPAN intended to simplify building modular command line applications. None of them met my requirements, which are documented in DESIGN GOALS.
CLIF was designed to offer the following features...
CLI::Framework::Command::Meta. They are identical to regular commands except they hold a reference to the application within which they are running. This means they are able to "know about" and affect the application. For example, the built-in command 'Menu' is a Metacommand because it needs to produce a list of the other commands in its application.
In general, your commands should be designed to operate independently of the application, so they should simply inherit from CLI::Framework::Command. The Metacommand facility is useful but should only be used when necessary.
noninteractive_commands method.name method. Names are handled case-sensitively throughout CLIF.When a command of the form:
$ app [app-opts] <cmd> [cmd-opts] { <cmd> [cmd-opts] {...} } [cmd-args]
...causes your application script, <app>, to invoke the run() > method in your application class, CLI::Framework::Application performs the following actions:
[app-opts], command name <cmd>, command options [cmd-opts], and the remaining part of the command line (which includes command arguments [cmd-args] for the last command and may include multiple subcommands; everything between the { ... } represents recursive subcommand processing).
If the command request is not well-formed, it is replaced with the default command and any arguments present are ignored. Generally, the default command prints a help or usage message.
These steps are explained in more detail below...
Your application class can optionally define the validate_options method.
If your application class does not override this method, validation is effectively skipped -- any received options are considered to be valid.
Your application class can optionally override the init method. This is an optional hook that can be used to perform any application-wide initialization that needs to be done independent of individual commands. For example, your application may use the init method to connect to a database and store a connection handle which is needed by most of the commands in the application.
Your application class can optionally have a pre_dispatch method that is called with one parameter: the Command object that is about to be dispatched. This hook is called in void context. Its purpose is to allow applications to do whatever may be necessary to prepare for running the command. For example, the pre_dispatch method could set a database handle in all command objects so that every command has access to the database. As another example, a log entry could be inserted as a record of the command being run.
CLIF uses the dispatch method to actually dispatch a specific command. That method is responsible for running the command or delegating responsibility to a subcommand, if applicable.
See dispatch for the specifics.
After building your CLIF-based application, in addition to basic non-interactive functionality, you will instantly benefit from the ability to (optionally) run your application in interactive mode. A readline-enabled application command console with an event loop, a command menu, and built-in debugging commands is provided by default.
This distribution comes with some default built-in commands, and more CLIF built-ins can be installed as they become available on CPAN.
Use of the built-ins is optional in most cases, but certain features require specific built-in commands (e.g. the Help command is a fundamental feature and the Menu command is required in interactive mode). You can override any of the built-ins.
The existing built-ins and their corresponding packages are as follows (for more information on each, see the respective documentation):
CLI::Framework::Comand::Help
NOTE: This command is registered automatically. It can be overridden, but a 'help' command is mandatory.
CLI::Framework::Comand::List
CLI::Framework::Comand::Dump
CLI::Framework::Comand::Tree
CLI::Framework::Comand::Console
CLI::Framework::Comand::Menu
NOTE: This command may be overridden, but the overriding command class MUST inherit from this one, conforming to its interface.
My::Application->new( interactive => 1 );
Construct a new CLIF Application object.
$app->is_valid_command( 'foo' );
Returns a true value if the specified command name is valid within the running application. Returns a false value otherwise.
$path = $app->command_search_path();
This method returns the path that should be searched for command class package files. If not overridden, the directory will be named 'Command' and will be under a sibling directory of your application class package named after the application class (e.g. if your application class is lib/My/App.pm, the default command search path will be lib/My/App/Command/).
@registered_commands = $app->get_registered_command_names();
Returns a list of the names of all registered commands.
my $command_object = $app->get_registered_command( $command_name );
Given the name of a registered command, returns the corresponding CLI::Framework::Command object. If the command is not registered, returns undef.
# Register by name...
$command_object = $app->register_command( $command_name );
# ...or register by object reference...
$command_object = CLI::Framework::Command->new( ... );
$app->register_command( $command_object );
Register a command to be recognized by the application. This method accepts either the name of a command or a reference to a CLI::Framework::Command object.
If a CLI::Framework::Command object is given and it is one of the commands specified to be valid, the command is registered and returned.
For registration by command name, an attempt is made to find the command with the given name. Preference is given to user-defined commands over built-ins, allowing user-defined versions to override built-in commands of the same name. If a user-defined command cannot be created, an attempt is made to register a built-in command by the given name. If neither attempt succeeds, an exception is thrown.
NOTE that registration of a command with the same name as one that is already registered will cause the existing command to be replaced by the new one. The commands registered within an application must be unique.
my $default = $app->get_default_command();
Retrieve the name of the default command.
$app->set_default_command( 'fly' );
Given a command name, makes it the default command for the application.
$status = $app->run();
print 'The command named: ', $app->get_current_command(), ' has completed';
Returns the name of the current command (or the one that was most recently run).
$app->set_current_command( 'roll' );
Given a command name, forward execution to that command. This might be useful (for example) in an application's init() method to redirect to another command.
$usage_msg = $app->get_default_usage();
Get the default usage message for the application. This message is used as a last resort when usage information is unavailable by other means. See usage|/usage.
$app->set_default_usage( $usage_message );
Set the default usage message for the application. This message is used as a last resort when usage information is unavailable by other means. See usage|/usage.
# Application usage...
print $app->usage();
# Command-specific usage...
print $app->usage( $command_name, @subcommand_chain );
Returns a usage message for the application or a specific command.
If a command name is given, returns a usage message string for that command. If no command name is given or if no usage message is defined for the specified command, returns a general usage message for the application.
Logically, here is how the usage message is produced:
# Get the entire session hash...
$app->session();
# Get the value of an item from the session...
$app->session( 'key' );
# Set the value of an item in the session...
$app->session( 'key' => $value );
CLIF Applications may have a need for global data shared between all components (individual CLIF Commands and the Application object itself). session provides a way for this data to be stored, retreived, and shared between components.
MyApp->run();
# ...or...
$app->run();
This method controls the request processing and dispatching of a single command. It takes its input from @ARGV (which may be populated by a script running non-interactively on the command line) and dispatches the indicated command, capturing its return value. The command's return value should represent the output produced by the command. It is a scalar that is passed to render for final display.
if( $app->is_interactive() ) {
print "running interactively";
}
Accessor for the interactivity state of the application.
$app->set_interactivity_mode(1);
Set the interactivity state of the application. One parameter is accepted: a true or false value for whether the application state should be interactive or non-interactive, respectively.
$help_command_is_interactive = $app->is_interactive_command( 'help' );
Determine if the command with the specified name is an interactive command (i.e. whether or not the command is enabled in interactive mode). Returns a true value if it is; returns a false value otherwise.
my @interactive_commands = $app->get_interactive_commands();
Return a list of all commands that are to be shown in interactive mode ("interactive commands").
MyApp->run_interactive();
# ...or...
$app->run_interactive();
Wrap the run method to create an event processing loop to prompt for and run commands in sequence. It uses the built-in command menu (or a user-defined menu-command, if one exists) to display available command selections.
Within this loop, valid input is the same as in non-interactive mode except that application options are not accepted (any application options should be handled before the interactive command loop is entered -- see the initialize parameter below).
The following parameters are recognized:
initialize: cause any options that are present in @ARGV to be procesed. One example of how this may be used: allow run_interactive() to process/validate application options and to run init prior to entering the interactive event loop to recognize commands.
invalid_request_threshold: the number of unrecognized command requests the user can enter before the menu is re-displayed.
$app->read_cmd();
This method is responsible for retreiving a command request and placing the tokens composing the request into @ARGV. It is called in void context.
The default implementation uses Term::ReadLine to prompt the user and read a command request, supporting command history.
Subclasses are encouraged to override this method if a different means of accepting user input is needed. This makes it possible to read command selections without assuming that the console is being used for I/O.
$app->render( $output );
This method is responsible for presentation of the result from a command. The default implementation simply attempts to print the $output scalar, assuming that it is a string.
Subclasses are encouraged to override this method to provide more sophisticated behavior such as processing the <$output> scalar through a templating system, if desired.
until( $app->is_quit_signal( $string_read_from_user ) ) { ... }
Given a string, return a true value if it is a quit signal (indicating that the application should exit) and a false value otherwise. quit_signals is an application subclass hook that defines what strings signify that the interactive session should exit.
There are several hooks that allow CLIF applications to influence the command execution process. This makes customizing the critical aspects of an application as easy as overriding methods. Subclasses can (and must, in some cases, as noted) override the following methods:
Overriding this hook is optional. It is called as follows:
$app->init( $app_options );
$app_options is a hash of pre-validated application options received and parsed from the command line. The option hash has already been checked against the options defined to be accepted by the application in option_spec.
This method allows CLIF applications to perform any common global initialization tasks that are necessary regardless of which command is to be run. Some examples of this include connecting to a database and storing a connection handle in the shared session slot for use by individual commands, setting up a logging facility that can be used by each command, or initializing settings from a configuration file.
Overriding this hook is optional. It is called as follows:
$app->pre_dispatch( $command_object );
This method allows applications to perform actions after each command object has been prepared for dispatch but before the command dispatch actually takes place.
Overriding this hook is optional. An example of its definition is as follows:
sub option_spec {
(
[ 'verbose|v' => 'be verbose' ],
[ 'logfile=s' => 'path to log file' ],
)
}
This method should return an option specification as expected by the Getopt::Long::Descriptive function describe_options. The option specification defines what options are allowed and recognized by the application.
This hook is optional. It is provided so that applications can perform validation of received options. It is called as follows:
$app->validate_options( $app_options );
$app_options is an options hash for the application.
This method should throw an exception (e.g. with die()) if the options are invalid.
NOTE that Getop::Long::Descriptive, which is used internally for part of the options processing, will perform some validation of its own based on the option_spec. However, the validate_options hook allows additional flexibility (if needed) in validating application options.
Overriding this hook is optioal. It allows aliases for commands to be specified. The aliases will be recognized in place of the actual command names. This is useful for setting up shortcuts to longer command names.
An example of its definition:
sub command_alias {
{
h => 'help',
l => 'list',
ls => 'list',
sh => 'console',
c => 'console',
}
}
Overriding this hook is optional. An example of its definition is as follows:
sub valid_commands { qw( console list my-custom-command ... ) }
The hook should return a list of the names of each command that is to be supported by the application. If not overridden by the application subclass, the application will be very generic and have only the default commands.
Command names must be the same as the values returned by the name method of the corresponding Command class.
Overriding this hook is optional.
Certain commands do not make sense to run interactively (e.g. the "console" command, which starts interactive mode). This method should return a list of their names. These commands will be disabled during interactive mode. By default, all commands are interactive commands except for console and menu.
Overriding this hook is optional.
sub quit_signals { qw( q quit exit ) }
An application can specify exactly what input represents a request to end an interactive session. By default, the three strings above are used.
To provide application usage information, this method may be defined. It should return a string containing a useful help message for the overall application.
CLIF aims to make things simple for CLIF-derived applications. OO Exceptions are used internally, but CLIF apps are free to handle errors using any desired strategy.
The main implication is that Application and Command class hooks such as CLI::Framework::Application::validate_options() and CLI::Framework::Command::validate() are expected to indicate success or failure by throwing exceptions. The exceptions can be plain calls to die() or can be Exception::Class objects.
Details will be provided pending finalizing error handling policies
For interactive usage, Term::ReadLine is used. Depending on which readline libraries are available on your system, your interactive experience will vary (for example, systems with GNU readline can benefit from a command history buffer).
Carp
Getopt::Long::Descriptive
Class::Inspector
File::Spec
Text::ParseWords (only for interactive use)
Term::ReadLine (only for interactive use)
CLI::Framework::Exceptions
CLI::Framework::Command
The CLIF distribution (CLI::Framework::*) is a work in progress! The current release is already quite effective, but there are several aspects that I plan to improve.
The following areas are currently targeted for improvement:
I plan another release soon that will offer some or all of these improvements. Suggestions and comments are welcome.
Many thanks to my colleagues at Informatics Corporation of America who have assisted by providing ideas and bug reports, especially Allen May.
Copyright (c) 2009 Karl Erisman (karl.erisman@icainformatics.com), Informatics Corporation of America. All rights reserved.
This is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See perlartistic.
Karl Erisman (karl.erisman@icainformatics.com)
