AlkantarClanX12
Your IP : 3.145.58.90
eZ component: ConsoleTools, Design, 1.3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:Author: Tobias Schlitt
:Revision: $Rev$
:Date: $Date$
:Status: Draft
.. contents::
=====
Scope
=====
The scope of this document is to describe the enhancements of the ConsoleTools
component for version 1.3 of the component. The following features are part of
this design document:
- Basic dialog system to interact with a user through STDIN.
- Enhanced handling of arguments (including help output).
This document describes a new range of classes, which will be added to
ConsoleTools, to fulfill this needs.
=============
Dialog system
=============
Design overview
===============
The following section gives a brief introduction of the concept of a simple
dialog system that enables the developer of a console based application to
interact with the user through STDIN.
Clarification of terms
----------------------
User
^^^^
The "user" is the person using a program and interacting with it during
runtime. The user has no knowledge about the internals and must be guided
through the dialog system he is interacting with. The term "user" in case of
this document is _not_ the developer using the described component, but the
user who interacts with the final program.
Developer
^^^^^^^^^
In contrast to the "user", the term "developer" in this document refers to the
person who creates a program, using the described component.
Dialog
^^^^^^
The basic idea of a new mechanism to interact with the user through STDIN in
this document is called a "dialog". A dialog is presented to the user by a
certain amount of output it generates and a certain amount of input it
requests afterwards.
Basic design
------------
The core of the new feature described in this document is a dialog. The dialog
is an object, must have the following capabilities:
- Presents itself to the user on the command line
- Requests data from the user through STDIN.
- Validate the result for its purpose.
- Return the result to the developer.
A dialog is usually used in a loop, which displays the dialog over and over again
until it received a valid result.
Class design
============
The following classes will realize the idea of dialogs in ConsoleTools.
ezcConsoleDialog
----------------
This interface describes the external API, which is commonly used by developers
and other classes to interact with a dialog object. Each dialog class must
implement this interface.
__construct( ezcConsoleOutput $output, ezcConsoleDialogOptions $options )
The constructor of a dialog receives an instance of ezcConsoleOutput, which
it must use for presenting its output, when requested. In addition, it can
receive an option object, which must be an instance or subclass instance of
ezcConsoleDialogOptions.
hasValidResult()
This method must return a boolean value, which indicates, if the dialog
already received a result from the user, which is valid in its context.
getResult()
After the hasValidResult() method returned true, this method will return the
value received from the dialog.
display()
Using this method, the developer can instruct the dialog object to display
itself to the user. The dialog must use the instance of eczConsoleOutput it
received in the constructor for displaying.
reset()
This method resets the dialog internally to the state it had directly after
construction, so that it can be reused by the developer.
In addition to this interface, an implementation of ezcConsoleDialog can
contain a set of static factory methods, which return a dialog in a
pre-configured state (for example a standard yes/no question, where only the
text needs to be set).
ezcConsoleDialogOptions
-----------------------
This is the base option class, which must be accepted by a dialog. It contains
options, which must be valid for each dialog class. A dialog class may request,
that the options it receives are instances of a subclass, if it expects
additional options. Each of the options defined in ezcConsoleDialogOptions must
also be available in this subclass. Every option defined must have a sensible
default value, so that there is no need for the developer to change it.
The base option class provides the following options:
format
The name of the format this dialog uses to be displayed. The format
identifier must be defined in the ezcConsoleOutput instance submitted to the
constructor of the dialog.
validator
An instance of ezcConsoleDialogValidator. This validator is responsible for
validation and manipulation of the result a dialog received from the user. An
implementation of ezcConsoleDialog may require a specific sub-class of
ezcConsoleDialogValidator here (e.g. for a menu dialog, which requires a
special validator object to work).
ezcConsoleDialogViewer
----------------------
The ezcConsoleDialogViewer class provides a set of static convenience methods
that can be used by a developer that works with dialogs and by a developer that
creates new dialogs. These methods are:
displayDialog( ezcConsoleDialog $dialog ) [static]
This method is recommended to be used for displaying dialogs. It performs the
typical loop: Display the dialog over and over again until it received a
valid result. When this state is reached, it returns the dialogs value.
readLine( $trim = true ) [static]
The readLine() method is commonly used in a dialog implementation to read a
line from standard in. It returns the input provided by a user, optionally
trimmed of leading and trailing white spaces.
ezcConsoleDialogValidator
-------------------------
The ezcConsoleValidator interface provides signatures for methods that can be used
by a dialog to validate the result it retrieved. The validator is configured by
the user and submitted to the dialog via an option (if a dialog supports this
mechanism).
__construct( ... )
The signature of the constructor is left to the validator implementation to
retrieve settings (e.g. the valid results).
validate( mixed $result )
This method is responsible for validating a given result. The dialog will
submit the result it received to this method which will indicate if the
result was valid by a boolean value. To manipulate / fix a retrieved result,
the dialog implementation can call the fixup() method.
fixup( mixed $result )
A validator can try to fix a given result to be valid. This manipulation can
be omitted by simply returning the result again. An example for a fixup would
be to convert a date information into a Unix timestamp using strtotime(). The
validate method would then expect an integer value > 0. The dialog
implementation is responsible for calling fixup() as it thinks is appropriate
(e.g. always before calling validate(), only if validate() fails, never).
Dialog implementations
======================
The new feature set comes with a collection of basic dialog implementations,
which will be described in this section.
ezcConsoleQuestionDialog
------------------------
The ezcConsoleQuestionDialog is the most basic imaginable dialog. It asks the
user a simply question and expects a certain answer. A typical output from an
ezcConsoleQuestionDialog object could look like this: ::
Do you want to continue? (y/n)
This dialog implementation provides a set of rudimentary options, which can be
used to customize its appearance and enhance its capabilities. For this
purpose, it comes with a custom options class ezcConsoleQuestionDialogOptions,
that accepts the following options in addition to those provided by
ezcConsoleDialogOptions:
text
This option defines the main "question" text, displayed to the user.
validator
The validator is an instance of ezcConsoleQuestionDialogValidator. For
implementation details, see further below.
showResults
If this boolean option is set to true, the dialog will display the possible
result values behind the question text itself (retrieved from the validator).
If a default value is provided, it will also indicate, which one this is. For
example: ::
Do you want to continue? (y/n) [y]
While here "y" and "n" are valid results and "y" is the default result, which
is selected when simply skipping this question by hitting just <RETURN>.
ezcConsoleQuestionDialogValidator
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The interface if ezcConsoleQuestionValidator inherits from
ezcConsoleDialogValidator and adds the following methods:
getResultString()
This method returns the result string to be displayed if the option
"showResults" is true in the ezcConsoleQuestionDialogOptions object.
Concrete implementations of these interface are:
ezcConsoleQuestionDialogTypeValidator
This validator checks the result to be of a given type (e.g. int, float). It
optionally checks if the result is in a given range (e.g. [0-100]).
ezcConsoleQuestionDialogCollectionValidator
This validator checks the result against a given collection of pre-defined
values (e.g. "y" and "n"). Beside that, it can perform basic operations on
the result before checking it (like strtolower()).
ezcConsoleQuestionDialogRegexValidator
This validator checks the result against a given regex (e.g.
"/([0-2]?[0-9])[:.]([0-6]?[0-9])/" for validation of a time value). In addition
it can perform a manipulation using this regex with a given (e.g. "\1:\2" to
unify the time value given).
ezcConsoleMenuDialog
--------------------
The second dialog implementation shipped with ConsoleTools is the menu dialog,
which is an enhanced version of the question dialog. The menu dialog will
display an ordered set of options and let the user select one of these. A
typical menu can look like this: ::
You can choose one of the following actions.
1) Create something new
2) Edit something
3) Delete something
4) Do something else
Please choose an action:
The menu dialog also comes with its own set of options, the
ezcConsoleMenuDialogOptions:
text
The text displayed before the menu.
selectionText
The text displayed after the menu to indicate to the user that he should make
a selection.
markerChar
The marker character used to divide the marker of a menu entry (e.g. the
number) from the menu value (the text of a menu entry).
validator
The validator must be an instance of ezcConsoleMenuDialogValidator.
ezcConsoleMenuDialogValidator
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In contrast to ezcConsoleQuestionDialogValidator, this is not an interface, but
a concrete implementation of ezcConsoleDialogValidator. The menu validator
offers 2 properties to determine the menu entries:
$entries
An array of entries shown as the menu. The keys of this array represent the
markers of the menu entries, the values represent the text shown.
In addition, the validator can be configured to perform a manipulation on the
result like the ezcConsoleQuestionDialogCollectionValidator (e.g.
strtolower()).
==============================
Enhanced handling of arguments
==============================
Design overview
===============
The current functionality for handling options and arguments for a console
based application in eZ Components (mainly the class ezcConsoleInput) has only
rudimentary support for dealing with arguments. The current possibility is to
either switch arguments on or off and does not allow to specify the following
things:
- How many arguments are possible
- Which arguments are mandatory/optional
- Names and types for the arguments.
The goal of this design section is to provide these 3 features for argument
handling.
Clarification of terms
----------------------
Parameter
^^^^^^^^^
The term parameter is a generic term, which covers options and arguments
together.
Option
^^^^^^
An option for a console based application is specified using a short or a long
name and can (optionally) carry a value of a given type. Short names are built
using "-<name>" syntax, long names use "--<name>". Options are already handled
by the ezcConsoleInput class, using objects of ezcConsoleOption.
Example: ::
foo.php --save "bar.txt" -a
"--save" is a long name and the parameter carries a string value "bar.txt".
"-a" is a short name of an option, while this option does not carry any value.
Argument
^^^^^^^^
In contrast to an option, an argument is not specified using a specific name, but
by by the order of submission to the program. Arguments can only be given to a
program, after all options have been specified.
Example: ::
foo.php --save "bar.txt" -a -- "baz" 23
"baz" is the value of the first argument, 23 the value of the second one.
Arguments separator
^^^^^^^^^^^^^^^^^^^
In some cases the semantic for specifying parameters on the console is not
deterministic. Since the algorithm used to parse parameters cannot handle
nondeterministic semantics, a separator must be used to determine the border
between options and arguments. The separator used is "-- ", which indicates
that anything following it is an argument and does not belong to the option
before it. The seperator is not mandatory and must only be used in cases where
the parsing would not be deterministic.
Example: ::
foo.php --save "bar.txt" -a "baz" 23
foo.php --save "bar.txt" -a -- "baz" 23
In the first line, it is not possible to determine if "baz" is the value for
the parameter "-a" or if it is an argument. The second line clarifies this.
Basic design
------------
The core of the new functionality is built upon 2 classes:
- ezcConsoleArguments
- ezcConsoleArgument
The first one is a collection class, which takes care of holding all arguments.
The second one is a struct class, which handles 1 specific argument.
Class design
============
ezcConsoleArgument
------------------
This struct class represents a single argument and defines the following
properties:
name
A descriptive name for the argument. This name is used for 2 purposes:
- Displaying it in the help text generated by ezcConsoleInput.
- Identifying and retrieving the object from the argument collection.
This property is mandatory and may not be left out.
type
The data type of the argument. The type is used for validation purposes when
the parameter string of the console application is parsed and is indicated to
the user in the help text generated by ezcConsoleInput. The default for this
property will be ezcConsoleInput::TYPE_STRING. ezcConsoleInput::TYPE_NONE
will not be allowed.
shorthelp
A short help text, which is used by ezcConsoleInput when generating a short
help output. A sensible default will be set for this property.
longhelp
A long help text, which is used by ezcConsoleInput when generating a long
help output. A sensible default will be set for this property.
mandatory
This boolean flag specifies if an argument is mandatory or optional. Since
ezcConsoleArguments is an ordered collection, all arguments following an
optional argument will be handled as optional, too. The default value for
this property is true.
default
This property carries the default value for optional arguments. If these are
not submitted, the default value will be used as the value property. If no
default value was explicitly defined, it is null and therefore the value
property will be null, if the argument was not submitted.
multiple
This booloan property determines, if an argument can carry multiple values.
The default here is false. If this is set to true, no more arguments may
follow the current argument, since multiple defines the number of values to
be undefined. If arguments would follow, the parameter string would be
non-deterministic. Therefore all following arguments are silently ignored.
For arguments with this property true, the returned value is an array. The
default value may be an array, too.
value
This property is not meant to be set by the developer directly, but by
ezcConsoleInput while parsing the parameter string of the application. It
will contain the value submitted for the argument after parsing. If this
argument was not submitted, the value of the default property will be set
here.
ezcConsoleArguments
-------------------
This collection class carries the arguments for an application. It keeps track
of the order of the ezcConsoleArgument objects and offers 2 access methods for
them:
- By their order (using numeric identification)
- By their name
For these purpose, the ArrayAccess and Iterator interfaces provided by PHP will
be implemented in this class. ArrayAccess will be used for both variants of
access, while Iterator will iterate of the numeric order of the arguments.
Argument names must be unique. The registration of new arguments is only
allowed by number. The retrival is also allowed by name.
The class does not offer any additional methods to deal with arguments and
purely relies on the given interfaces.
Integration aspects
===================
The current design of ezcConsoleInput is not designed to handle arguments in
the planned way. Therefore its API must be changed slightly. Naturally this
will be done maintaining BC. The following changes are planned:
Property $argumentDefinition
----------------------------
Since ezcConsoleInput already has a property $arguments, which carries the
values of submitted arguments in an array, a new property will be introduced to
carry the instance of ezcConsoleArguments. By default, this property will be
null, which indicates, that the old manor of handling arguments is used.
If ezcConsoleArguments is used, the preferred way of retrieving argument values
is, to use the ezcConsoleArgument struct of the specific argument. The
$arguments property of ezcConsoleInput will still be set and contain the values
of the provided arguments.
Switching arguments on/off
--------------------------
The ezcConsoleOption class allows to switch arguments on or off for a console
call to the application using its property $arguments. This behaviour will not
be changed. If an option defines that arguments are not allowed, if it is
submitted, all defined arguments will not be allowed.
It is possible, that this behaviour will be enhanced in the future, so that
options can define a filter rule for arguments instead of a boolean on/off
switch. But this feature is not in scope of the design given here.
Usage example
=============
The following example shows the basic of the newly created API.
Using arguments
---------------
::
$input = new ezcConsoleInput();
$input->argumentDefinition = new ezcConsoleArguments();
// First argument
$input->argumentDefinition[] = new ezcConsoleArgument(
"infile",
ezcConsoleInput::TYPE_STRING,
"The file to read from.",
"The input file, from which the content to process is read.",
);
// Second argument
$input->argumentDefinition[1] = new ezcConsoleArgument(
"outfile"
);
$input->argumentDefinition[1]->shorthelp = "Output file.";
$input->argumentDefinition[1]->longhelp = "File to output generated
content to. Output will be printed to STDOUT if left out.";
$input->argumentDefinition[1]->mandatory = false;
$input->argumentDefinition[1]->default = "php://output;
try
{
$input->process();
}
catch ( ezcConsoleMissingArgumentException $e )
{
// Only the first argument will possibly trigger this
die( "Argument {$e->argument->name} missing!" );
}
// The first argument is always present if no exception occured
$inFile = fopen( $input->argumentDefinition["infile"]->value, "r" );
// The second one is optional, but has a default
$outFile = fopen( $input->argumentDefinition["infile"]->value, "w" );
Generating help
---------------
::
$input = new ezcConsoleInput();
$input->argumentDefinition = new ezcConsoleArguments();
// First argument
$input->argumentDefinition[] = new ezcConsoleArgument(
"file",
ezcConsoleInput::TYPE_STRING,
"Output file.",
"File to output generated
);
// Second argument
$input->argumentDefinition[] = new ezcConsoleArgument(
"bytes",
ezcConsoleInput::TYPE_INT,
"Bytes to write.",
"The number of bytes written to the output file. If left out,
everything will be written.",
false,
-1
);
echo $input->getHelpiText( "Some example program." );
Generates: ::
Usage: test.php [--] <string:file> [<int:bytes>]
Some example program
Arguments:
<string:file> Output file.
<int:bytes> = -1 Bytes to write.
Open issues
===========
- The access of arguments by number and name is comfortable, but (as described
above) not reliable, if 2 parameters have the same name. It also makes
implementation more complex (if a parameter is removed, namesake has to come
in place. So, do we want this or not?
- The property name $argumentsDefinition is OK for the definition part, but
does actually not make sense, if you access it later to retrieve the value.
Any better naming solution?
- It is sometimes sensible to allow that for 1 argument multiple values are
submitted (e.g. if you expect an undefined number of file names). To resolve
this, we need to invent a property "multiple" for the ezcConsoleArgument
struct. If multiple is defined for 1 argument, no more arguments must follow,
since the algorithm could not determine easily where the multiple values for
the argument end. Do we need this functionality (now)?
..
Local Variables:
mode: rst
fill-column: 79
End:
vim: et syn=rst tw=79