Download the PHP package popphp/pop-console without Composer

pop-console

• Overview
• Install
• Quickstart
• Response Buffer
• Colors
• Lines
• Headers
• Alerts
• Prompt
• Table
• Progress Bar
• Utilities
• Commands
• Command Registry
• Help Screen

Overview

pop-console provides a layer to run an application from the console terminal and produce formatted output to the terminal window. It has support for commands and their parameters, as well ANSI-based console colors. It can be easily be used with an application built with Pop to route requests from the CLI to the application.

pop-console is a component of the Pop PHP Framework.

Note

The code below represents basic examples. Ideally, you could wire an application to use the console for outputting content to the terminal screen, but not for setting routes, controllers and actions. Refer to the Pop PHP Tutorial example application to see how to wire up a CLI-based application complete with routes using Pop PHP.

Top

Install

Install pop-console using Composer.

composer require popphp/pop-console

Or, require it in your composer.json file

"require": {
    "popphp/pop-console" : "^5.0.0"
}

Top

Quickstart

Outputting to the console

You can use a console object to manage and deploy output to the console, including a prepended header and appended footer.

The above will output:

Console wrap and margin

By default, the console object enforces a wrap width at 80 characters and provides a margin of 4 spaces for readability. These values can be changed to whatever is needed for the application.

Top

Response Buffer

Append vs Write

In the above examples, the method append() was used in conjunction with send(). The method append() appends the content to the response buffer, which will only get produced to the terminal screen when the method send() is called. This is useful if you have to take a number of steps to create the response buffer before sending it.

Using the method write() allows you to produce content to the terminal screen in real time, without having to call the send() method. This is useful if you need to push content out to the terminal screen of the application as you go.

Newline and Margin

By default, calling the append() or write() methods will produce the margin value at the beginning of the content and a newline at the end of the content. If this is not the desired behavior, boolean flags can be passed to control this:

Top

Colors

On a console terminal that supports it, you can colorize text outputted to the console with the colorize() method:

The colorize() method is also available as a static method on the Pop\Console\Color class:

Available color constants include:

• NORMAL
• BLACK
• RED
• GREEN
• YELLOW
• BLUE
• MAGENTA
• CYAN
• WHITE
• BRIGHT_BLACK
• BRIGHT_RED
• BRIGHT_GREEN
• BRIGHT_YELLOW
• BRIGHT_BLUE
• BRIGHT_MAGENTA
• BRIGHT_CYAN
• BRIGHT_WHITE
• BOLD_BLACK
• BOLD_RED
• BOLD_GREEN
• BOLD_YELLOW
• BOLD_BLUE
• BOLD_MAGENTA
• BOLD_CYAN
• BOLD_WHITE
• BRIGHT_BOLD_BLACK
• BRIGHT_BOLD_RED
• BRIGHT_BOLD_GREEN
• BRIGHT_BOLD_YELLOW
• BRIGHT_BOLD_BLUE
• BRIGHT_BOLD_MAGENTA
• BRIGHT_BOLD_CYAN
• BRIGHT_BOLD_WHITE

Top

Lines

The line() method provides a way to print a horizontal line rule out to the terminal. The default character for the line is a dash -, but any character can be passed into the method.

It will default to the wrap width of the console object. If no wrap width is available, it will take on the width of the terminal, unless a custom width is specified:

Top

Headers

The header() method provides a way to output a separate block of text with an underline emphasis:

The character, size and alignment can be controlled as well:

The headerLeft(), headerCenter() and headerRight() methods are shortcuts for header() with the alignment fixed accordingly, and default their $size to 'auto' (wrap width, falling back to terminal width):

Top

Alerts

Alerts are specially formatted boxes that provide style and enhancement to the user's experience in regard to important information and notifications.

The alertBox() method produces a colorless alert box with a border made of character strings. The above code will produce the following output to the console terminal:

Top

Prompt

You can trigger a prompt to get information from the user:

You can also enforce a certain set of options as well as case-sensitivity. The prompt will not accept a value outside of the provided range of option values. If the case-sensitive flag is set to true, the prompt will not accept values that are not an exact case-match.

Confirm

The confirm() method is a shorthand version of a prompt to ask if the user is sure they want to proceed, else the application will exit:

Testing prompts

By default, prompt() and confirm() read from php://stdin. To unit test code that prompts for input, inject a stream with setInputStream() — one line per expected answer, read the same way real stdin is:

hasInputStream() and getInputStream() are also available to check/retrieve the injected stream.

Top

Table

The table() method renders headers and rows into a bordered grid. Border characters are configurable, and the header row can be colorized:

Passing null for the vertical border character omits the column dividers, leaving just top/bottom horizontal rules:

Like line(), header() and alertBox(), passing true as the last argument returns the rendered string instead of echoing it.

Top

Progress Bar

The progressBar() method returns a Pop\Console\ProgressBar object for tracking the progress of a long-running task. Unlike the other output methods, it doesn't echo-or-return a single string — it redraws the same terminal line in place as you advance it:

advance(int $step = 1) moves the bar forward by $step; setProgress(int $current) sets it to an absolute value. Both clamp to [0, $total]. finish() forces the bar to 100% and prints a trailing newline so subsequent output starts on a fresh line.

Top

Utilities

A few additional helper methods are available on the console object:

Top

Commands

A command object allows you to define the name, parameters and help string values of a command and add the command to the console object:

A command can also be the dispatch target itself, rather than just carrying display metadata. Command implements Pop\Dispatch\DispatchableInterface, the same contract Pop\Controller\AbstractController implements, so a route can point directly at a Command subclass instead of a controller/action pair. Subclass Command and write a handle() method with whatever signature you need — there's no interface constraining it, so it can take no arguments, or any number of typed parameters the router resolves:

dispatch() resolves to handle() whenever no explicit action name is given, and always passes $params through. If a Command subclass has no handle() method defined, dispatch() throws a Pop\Dispatch\Exception.

A Command carries the Application and Console objects it needs to do its work via Pop\Dispatch\ConsoleTrait, the same trait a full Pop\Controller\AbstractController uses — which is why they're the constructor's first two parameters, ahead of name/params/help, and can also be set after the fact with setApplication()/setConsole(). Console defaults to a fresh new Console(120) instance when not supplied, so hasConsole() is true out of the box; Application stays null until explicitly provided:

Top

Command Registry

The console object doesn't store commands itself — addCommand(), addCommands(), getCommands(), getCommand(), hasCommand(), getCommandsFromRoutes() and addCommandsFromRoutes() are all thin facades over a Pop\Console\CommandRegistry instance it holds internally. CommandRegistry is a plain, Console-independent object, so command bookkeeping can be used and tested on its own:

Loading routes from a directory of command classes

For applications that generate one Command subclass per file (one command per class, e.g. via a scaffolding tool), CommandRegistry::loadRoutes() scans a directory and builds a CLI routes config array from what it finds — namespace included, so it doesn't need to be passed in:

Each .php file in the directory is checked for a matching, loadable class (namespace parsed from the first file, class name from the filename). For each command class found, it's instantiated with no constructor arguments and keyed in the resulting array by its own (string) cast — so a command class is expected to set its own name/params in its constructor. If the command has help text (hasHelp()), that's carried over too, with a trailing newline appended to the last command's help so it doesn't run into whatever's appended after the help screen.

The third argument, $prepend (default true), controls merge order against the $routes passed in: when true, auto-discovered routes are merged first, so explicit routes with a matching key win; pass false to reverse that.

Top

Help Screen

Registering the commands with the console object like in the above example allows you to call the help() method to view the auto-generated help screen:

Passing a command name to help() returns just that command's help string instead of printing the full screen:

Filtering help by subcommand namespace

Both help() and displayHelp() take an optional third/second $subCommand argument (respectively) that narrows the help screen down to commands under a given namespace, so ./myapp help db: (or just ./myapp help db, the trailing : isn't required) only lists db:* commands instead of every registered command:

Matching is done against each command's own bare name with any registered script name (see below) stripped off first, checked with a simple prefix match — so it isn't tied to : as a namespace delimiter, and works the same way for space-separated command names like user list/user edit (help(null, false, 'user') matches both). A $subCommand that matches nothing renders an empty list rather than throwing.

However, the console object has the method addCommandsFromRoutes() which works in conjunction with a Pop\Router\Cli\Match object to automatically generate the command, along with their parameters and help strings.

This console will use the CLI route match object and parse out all of the commands and make them available for the console object to leverage for the help screen.

For each route, help text is taken from the route config's 'help' value if one is set. If it isn't, and the route's controller implements Pop\Console\Command\CommandInterface, the controller is instantiated (with no constructor arguments) and its own getHelp() is used instead — so a Command subclass with hardcoded help text doesn't need that help duplicated in the route config.

The script name passed to addCommandsFromRoutes()/getCommandsFromRoutes() ('./myapp' above) is also recorded on each Command it builds via setScriptName()/getScriptName()/hasScriptName(). That's what lets subcommand filtering (see Filtering help by subcommand namespace above) tell the script name apart from the command's own name, even when they happen to share a prefix — e.g. a script named dbapp won't cause help(null, false, 'db') to also match an unrelated user:list command. Commands registered directly via addCommand()/addCommands() have no script name recorded, and subcommand filtering matches their full name as-is.

Help colors

An extra layer of presentation control is available by way of setting the help screen colors. You can choose up to 4 colors that will be used in breaking apart the command strings by name and parameters and colorizing them to make the different segments standout in an organized fashion.

Let's take a look at the abstract constructor of the pop-kettle component.

In the above constructor method, the help colors are set and then the application object pushes the CLI route match object into the console method addCommandsFromRoutes(). The second parameter ./kettle is a script prefix to prepend to each line of help. Those two lines are all that is needed to produce the colorful and well organized help screen for pop-kettle, which is called within the controller's help() method.

The output looks like this:

Top