NAME
    CLI::Framework::Application - Build standardized, flexible, testable
    command-line applications

SYNOPSIS
        #---- 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

OVERVIEW
    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.

UNDERSTANDING CLIF: RECOMMENDATIONS
    "Quickstart" and "Tutorial" guides are currently being prepared for the
    next CLIF release. However, this early 0.01 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.

MOTIVATION
    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.

DESIGN GOALS/FEATURES
    CLIF was designed to offer the following features...

    *   A clear conceptual pattern for creating CLI apps

    *   Guiding documentation and examples

    *   Convenience for simple cases, flexibility for complex cases

    *   Support for both non-interactive and interactive modes (without
        extra work)

    *   Separation of Concerns to decouple data model, control flow, and
        presentation

    *   The possibility to share some components with MVC web apps

    *   Commands that can be shared between apps (and uploaded to CPAN)

    *   Validation of app options

    *   Validation of per-command options and arguments

    *   A model that encourages easily-testable applications

    *   Flexible way to provide usage/help information for the application
        as a whole and for individual commands

    *   Support for subcommands that work just like commands

    *   Support for recursively-defined subcommands (sub-sub-...commands to
        any level of depth)

    *   Support aliases for commands and subcommands

    *   Allow subcommand package declarations to be defined inline in the
        same file as their parent command or in separate files per usual
        Perl package file hierarchy organization

    *   Support the concept of a default command for the application

CONCEPTS AND DEFINITIONS
    *   Application Script - The wrapper program that invokes the CLIF
        Application's run method.

    *   Valid Commands - The set of command names available to a running
        CLIF-derived application. This set contains the
        client-programmer-defined commands and all registered built-in
        commands.

    *   Metacommand - An application-aware command. Metacommands are
        subclasses of "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.

        #FIXME-DOCUMENT:Tutorial will give design guidelines for how to use
        metacommands vs regular commands -- in general, an application
        should modify attributes of its commands instead of commands
        modifying application attributes (e.g. if a command needs a
        reference to an application-wide object stored in the app object,
        the app's init() method should set an attribute in the command
        instead of having the command be a metacommand, which holds a
        reference to the application).

    *   Non-interactive Command - In interactive mode, some commands need to
        be disabled. For instance, the built-in 'console' command should not
        be presented as a menu option in interactive mode because it is
        already running. You can designate which commands are
        non-interactive by overriding the "noninteractive_commands" method.

    *   Options hash - A Perl hash that is created by the framework based on
        user input. The hash keys are option names (from among the valid
        options defined in an application's option_spec method) and the
        values are the scalars passed by the user via the command line.

    *   Command names - The official name of each CLIF command is defined by
        the value returned by its "name" method. Names are handled
        case-sensitively throughout CLIF.

    *   Registration of commands - The CLIF Commands within an application
        must be registered with the application. The names of commands
        registered within an application must be unique.

APPLICATION RUN SEQUENCE
    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:

    1   Parse the application options "[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.

    2   Validate application options.

    3   Initialize application.

    4   Invoke command pre-run hook.

    5   Dispatch command.

    These steps are explained in more detail below...

  Validation of application options
    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.

  Application initialization
    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.

  Command pre-run
    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.

  Dispatching a command
    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.

INTERACTIVITY
    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.

BUILT-IN COMMANDS INCLUDED IN THIS DISTRIBUTION
    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):

    help
        CLI::Framework::Comand::Help

        NOTE: This command is registered automatically. It can be
        overridden, but a 'help' command is mandatory.

    list
        CLI::Framework::Comand::List

    dump
        CLI::Framework::Comand::Dump

    tree
        CLI::Framework::Comand::Tree

    console
        CLI::Framework::Comand::Console

    menu
        CLI::Framework::Comand::Menu

        NOTE: This command may be overridden, but the overriding command
        class MUST inherit from this one, conforming to its interface.

METHODS: OBJECT CONSTRUCTION
  new
        My::Application->new( interactive => 1 );

    Construct a new CLIF Application object.

METHODS: COMMAND INTROSPECTION & REGISTRATION
  is_valid_command
        $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.

  command_search_path
        $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/).

  get_registered_command_names
        @registered_commands = $app->get_registered_command_names();

    Returns a list of the names of all registered commands.

  get_registered_command
        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_command
        # 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.

METHODS: PARSING & RUNNING COMMANDS
  get_default_command
        my $default = $app->get_default_command();

    Retrieve the name of the default command.

  set_default_command
        $app->set_default_command( 'fly' );

    Given a command name, makes it the default command for the application.

  get_current_command
        $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).

  set_current_command
        $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.

  get_default_usage
        $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.

  set_default_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.

  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:

    *   If a valid command name is given, attempt to get usage message from
        the command; if no usage message is defined for the command, use the
        application usage message instead.

    *   If the application object has defined usage_text, use its return
        value as the usage message.

    *   Finally, fall back to using the default usage message returned by
        get_default_usage.

  session
        # 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.

  run
        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.

METHODS: INTERACTIVITY
  is_interactive
        if( $app->is_interactive() ) {
            print "running interactively";
        }

    Accessor for the interactivity state of the application.

  set_interactivity_mode
        $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.

  is_interactive_command
        $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.

  get_interactive_commands
        my @interactive_commands = $app->get_interactive_commands();

    Return a list of all commands that are to be shown in interactive mode
    ("interactive commands").

  run_interactive
        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.

  read_cmd
        $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.

  render
        $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.

  is_quit_signal
        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.

METHODS: SUBCLASS HOOKS
    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:

  init
    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.

  pre_dispatch
    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.

  option_spec
    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.

  validate_options
    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.

  valid_commands
    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.

  noninteractive_commands
    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".

  quit_signals
    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.

  usage_text
    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 ERROR HANDLING POLICY
    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.

DIAGNOSTICS
    FIXME: Details will be provided pending finalizing error handling
    policies

CONFIGURATION & ENVIRONMENT
    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).

DEPENDENCIES
    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

DEFECTS AND LIMITATIONS
    The CLIF distribution (CLI::Framework::*) is a work in progress! The
    current 0.01 release is already quite effective, but there are several
    aspects that I plan to improve.

    The following areas are currently targeted for improvement:

    *   Interface -- Be aware that the interface may change. Most likely,
        the changes will be small.

    *   Error handling -- Exception objects are being used successfully, but
        more thorough planning needs to be done to finalize error handling
        policies.

    *   Feature set -- Possible additional features being considered
        include: enhanced support for using templates to render output of
        commands (including output from error handlers); an optional
        constructor with an interface that will allow the application and
        its commands to be defined inline, making it possible to generate an
        application without creating separate files to inherit from the base
        framework classes; a "web console" that will make the interactive
        mode available over the web.

    *   Documentation -- "Quickstart" and "Tutorial" guides are being
        written.

    I plan another release soon that will offer some or all of these
    improvements. Suggestions and comments are welcome.

ACKNOWLEDGEMENTS
    Many thanks to my colleagues at Informatics Corporation of America who
    have assisted by providing ideas and bug reports, especially Allen May.

SEE ALSO
    CLI::Framework::Command

LICENSE AND COPYRIGHT
    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.

AUTHOR
    Karl Erisman (karl.erisman@icainformatics.com)