[comment {-*- tcl -*- doctools manpage}]
[include parts/definitions.inc]
[manpage_begin [vset PROJECT] [vset MAN_SECTION] [vset VERSION]]
[include parts/module.inc]
[require cmdr::util]
[titledesc [vset TITLE_MAIN]]
[description]
[include parts/welcome.inc]
This is the main package of the framework, its public entry point.
It provides four commands for setup and configuration of command
................................................................................
[para] The result of the command is the new instance command.
[list_begin arguments]
[arg_def string name]
The user-visible name of the command (hierarchy).
[arg_def script actions]
The specification of the subordinate commands. On the command line
these are the toplevel commands of the application using the
hierarchy. Please read [term [vset TITLE_DSL]], (section "Officers")for the details.
[list_end][comment arguments]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd ::cmdr] [method interactive] [opt [arg enable]]]
This command globally (de)activates the interactive parts of the

[comment {-*- tcl -*- doctools manpage}]
[include parts/definitions.inc]
[manpage_begin [vset PROJECT] [vset MAN_SECTION] [vset VERSION]]
[include parts/module.inc]
[require cmdr]
[titledesc [vset TITLE_MAIN]]
[description]
[include parts/welcome.inc]
This is the main package of the framework, its public entry point.
It provides four commands for setup and configuration of command
................................................................................
[para] The result of the command is the new instance command.
[list_begin arguments]
[arg_def string name]
The user-visible name of the command (hierarchy).
[arg_def script actions]
The specification of the subordinate commands. On the command line
these are the toplevel commands of the application using the
hierarchy. Please read [term [vset TITLE_DSL_OFFICER]] for the
details.
[list_end][comment arguments]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd ::cmdr] [method interactive] [opt [arg enable]]]
This command globally (de)activates the interactive parts of the

[include parts/welcome.inc]
This document is for users of the cmdr framework. It introduces the
domain-specific language for the specification of command hierarchies
with commands and their parameters by way of examples and then
provides links to the detailed reference documents.
[para] These related documents are:
[include parts/related_dsl.inc]
[comment @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@]
[section {Introductory examples}]
Instead of immediately diving into the full syntax of the
specification language first a few examples to demonstrate the general
look and feel, plus basic features.
[comment ================================================]
[subsection {Basic setup, private with inputs}]
[include parts/ex_alias0.inc]
[comment ================================================]
[subsection {Basic setup, command nesting}]
[include parts/ex_alias1.inc]
[comment @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@]
[section {Language Reference}]
With the examples behind us we can now go and specify the entire
specification language. If you have skipped here on first reading,
ignoring the examples, please go back and read them first.
[include parts/dsl_general.inc]
[para] For the details please continue reading at[include parts/related_dsl.inc]
[include parts/related.inc]
[include parts/feedback.inc]
[manpage_end]

[include parts/welcome.inc]
This document is for users of the cmdr framework. It introduces the
domain-specific language for the specification of command hierarchies
with commands and their parameters by way of examples and then
provides links to the detailed reference documents.
[include parts/related_dsl.inc]
[comment @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@]
[section {Introductory examples}]
Instead of immediately diving into the full syntax of the
specification language first a few examples to demonstrate the general
look and feel, plus basic features.
[comment ================================================]
[subsection {Basic private commands with inputs}]
[include parts/ex_alias0.inc]
[comment ================================================]
[subsection {Simple command nesting}]
[include parts/ex_alias1.inc]
[comment @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@]
[section {Language Reference}]
With the examples behind us we can now go and specify the entire
specification language. If you have skipped here on first reading,
ignoring the examples, please go back and read them first.
[include parts/dsl_general.inc]
[para] Please continue reading with [term [vset TITLE_DSL_OFFICER]].
[include parts/related.inc]
[include parts/feedback.inc]
[manpage_end]

[comment {-*- tcl -*- doctools manpage}]
[include parts/definitions.inc]
[manpage_begin [vset PROJECT]_officer [vset MAN_SECTION] [vset VERSION]]
[include parts/module.inc]
[require cmdr::util]
[titledesc [vset TITLE_OFFICER]]
[description]
[include parts/welcome.inc]
This package implements [emph officers], the inner nodes of command
hierarchies. Each officer can execute many actions, by delegating
them to their sub-ordinate actors, officers and privates.
................................................................................
The instance command of the actor (officer actually) which contains the new officer.
[arg_def string name]
The user-visible name of the command.
[arg_def script actions]
The specification of the officer's subordinates.
Please read [term [vset TITLE_DSL]] (section "Officers") for the details.
[list_end][comment arguments]
[list_end][comment definitions]
[comment @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@]
[section {Instance API}]
................................................................................
The list of names specifying the route from this officer to the new
private. The last element is the name of the private command, while
the preceding names specify the intermediate officers.
[comment {--- TODO place into text block for inclusion --- see private - constructor}]
[arg_def script arguments]
The specification of the private's parameters.
Please read [term [vset TITLE_DSL]] (section "Parameters") for the details.
[arg_def cmd-prefix action]
The command prefix to invoke when this private is selected for
execution. It takes a single argument, the instance command of the
hidden [package cmdr::config] container holding the private's
parameters. The result of the action, if there is any, is ignored by
the framework.
................................................................................
the set of subordinates known to this officer. This is the same type
of script as used during construction, except here we dynamically
extend the officer.
[list_begin arguments]
[arg_def script actions]
The specification of the officer's additional subordinates.
Please read [term [vset TITLE_DSL]] (section "Officers") for the details.
[list_end][comment arguments]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd <officer>] [method lookup] [arg name]]
This method returns the instance command of the sub-ordinate with the

[comment {-*- tcl -*- doctools manpage}]
[include parts/definitions.inc]
[manpage_begin [vset PROJECT]::officer [vset MAN_SECTION] [vset VERSION]]
[include parts/module.inc]
[require cmdr::officer]
[titledesc [vset TITLE_OFFICER]]
[description]
[include parts/welcome.inc]
This package implements [emph officers], the inner nodes of command
hierarchies. Each officer can execute many actions, by delegating
them to their sub-ordinate actors, officers and privates.
................................................................................
The instance command of the actor (officer actually) which contains the new officer.
[arg_def string name]
The user-visible name of the command.
[arg_def script actions]
The specification of the officer's subordinates.
Please read [term [vset TITLE_DSL_OFFICER]] for the details.
[list_end][comment arguments]
[list_end][comment definitions]
[comment @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@]
[section {Instance API}]
................................................................................
The list of names specifying the route from this officer to the new
private. The last element is the name of the private command, while
the preceding names specify the intermediate officers.
[comment {--- TODO place into text block for inclusion --- see private - constructor}]
[arg_def script arguments]
The specification of the private's parameters.
Please read [term [vset TITLE_DSL_PARAMETER]] for the details.
[arg_def cmd-prefix action]
The command prefix to invoke when this private is selected for
execution. It takes a single argument, the instance command of the
hidden [package cmdr::config] container holding the private's
parameters. The result of the action, if there is any, is ignored by
the framework.
................................................................................
the set of subordinates known to this officer. This is the same type
of script as used during construction, except here we dynamically
extend the officer.
[list_begin arguments]
[arg_def script actions]
The specification of the officer's additional subordinates.
Please read [term [vset TITLE_DSL_OFFICER]] for the details.
[list_end][comment arguments]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd <officer>] [method lookup] [arg name]]
This method returns the instance command of the sub-ordinate with the

[comment {-*- tcl -*- doctools manpage}]
[include parts/definitions.inc]
[manpage_begin [vset PROJECT]_private [vset MAN_SECTION] [vset VERSION]]
[include parts/module.inc]
[require cmdr::util]
[titledesc [vset TITLE_PRIVATE]]
[description]
[include parts/welcome.inc]
This package implements [emph privates], the leaves of command
hierarchies. While each private can execute only a single action they
have parameters, i.e. arguments and options with which to configure
................................................................................
[arg_def string name]
The user-visible name of the command.
[comment {--- TODO place into text block for inclusion --- see officer - extend}]
[arg_def script arguments]
The specification of the private's parameters.
Please read [term [vset TITLE_DSL]] (section "Privates") for the details.
[arg_def cmd-prefix action]
The command prefix to invoke when this private is selected for
execution. It takes a single argument, the instance command of the
hidden [package cmdr::config] container holding the private's
parameters. The result of the action, if there is any, is ignored by
the framework.

[comment {-*- tcl -*- doctools manpage}]
[include parts/definitions.inc]
[manpage_begin [vset PROJECT]::private [vset MAN_SECTION] [vset VERSION]]
[include parts/module.inc]
[require cmdr::private]
[titledesc [vset TITLE_PRIVATE]]
[description]
[include parts/welcome.inc]
This package implements [emph privates], the leaves of command
hierarchies. While each private can execute only a single action they
have parameters, i.e. arguments and options with which to configure
................................................................................
[arg_def string name]
The user-visible name of the command.
[comment {--- TODO place into text block for inclusion --- see officer - extend}]
[arg_def script arguments]
The specification of the private's parameters.
Please read [term [vset TITLE_DSL_PRIVATE]] for the details.
[arg_def cmd-prefix action]
The command prefix to invoke when this private is selected for
execution. It takes a single argument, the instance command of the
hidden [package cmdr::config] container holding the private's
parameters. The result of the action, if there is any, is ignored by
the framework.

[manpage_begin [vset PROJECT]_vtypes [vset MAN_SECTION] [vset VERSION]]
[include parts/module.inc]
[require cmdr::validate]
[titledesc [vset TITLE_DEV_VT]]
[description]
[include parts/welcome.inc]
This document describes the API expected of validation types to make
them usable within the [vset PTITLE] framework, and how to write a
custom validation type.
[para] Readers interested in the standard validation types of the
framework should read [term [vset TITLE_VALIDATE]].
[section Background]
Validation types are [vset PTITLE]'s answer to the necessity of moving
................................................................................
[para] Because of the same necessity all parameters must have a
validation type assigned to them, and the framework will choose which,
if the user did not. This choice is made per the six rules below and
always returns one of the builtins described in [term [vset TITLE_VALIDATE]].
[list_begin enumerated]
[enum] Use [const identity] if a [cmd generate] callback is specified.
[enum] Use [const boolean] if no [cmd default] is specified and the parameter is an option.
[enum] Use [const identity] if no [cmd default] is specified and the parameter is an input.
[enum] Use [const boolean] if the specified [cmd default] value is a Tcl boolean.
[enum] Use [const integer] if the specified [cmd default] value is a Tcl integer.
[enum] Use [const identity] as fallback of last resort.
[list_end]
[para] The general concept of validation types was taken from package
[package snit], and modified to suit [vset PTITLE]. Where snit's types
expect only a single method to validate the input we expect all types
to support an ensemble of [emph four] methods. One for the basic
validation and transformation of the input, another for the release of
any internal representation so generated, plus two more for delivery
of a default representation and support for command line completion.
The details (method names, signatures, etc.) can be found in section
[sectref API] below.
[para] As an example the implementation of the standard boolean
validation type is shown in section [sectref Example].
[para] It should be noted that while snit's validation types in
principle allow for the transformation of input into a disparate
internal representation, they never went so far as to allow complex
representations which might require the release of resources after
use.
[para] The [cmd validate] and [cmd release] methods are primarily used
during either completion or execution phases, depending on the chosendeferal state. They may also be used during parsing, for optional
inputs under the [cmd test]-regime].
[para] The [cmd complete] method will be used whereever the system
activates an interactive command line shell where arguments may be
assigned to parameters.
[para] The [cmd default] method on the other hand can expect to be
invoked during dispatch, as part of the system's declaration
processing, if not preempted by [cmd default] and [cmd generate]
declarations for the parameter. Note here that the [cmd default]method has the same signature as a [cmd generate] callback and can be
used as such. This is actually needed and useful when the default
internal representation for a validation type cannot be expressed as a
fixed value and its creation while parsing the specification itself is
too early. We can still use the validation type for its generation, by
hooking it explicitly into [cmd generate] to change the timing of its
invokation.
[section API]
In the descriptions below the [cmd cmd] is a placeholder for the
actual command prefix, most often a main command, of the validation
type.
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd cmd] [method complete] [arg p] [arg x]]
This method is invoked during command completion done by the framework.
[para] It has to return the list of legal string representations for
the type and parameter instance [arg p] which have the incomplete word
[arg x] as their prefix.
................................................................................
custom type may have need for access to the context of the completion.
[arg_def string x]
The string value to complete.
[list_end]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd cmd] [method default] [arg p]]
This method is invoked when the framework has to determine the
internal representation of a parameter which has no user-specified
string representation.
[para] It has to return the default internal representation for
the type and parameter instance [arg p].
................................................................................
do not make use of it a custom type may have need for access to the
context.
[arg_def string x]
The string value to complete.
[list_end]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd cmd] [method release] [arg p] [arg x]]
This method is invoked when the framework has to get rid of an
internal representation for a parameter.
[para] It has to release any resources associated with the internal
representation [arg x] of parameter instance [arg p].
................................................................................
of the completion.
[arg_def string x]
The internal representation to release.
[list_end]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd cmd] [method validate] [arg p] [arg x]]
This method is invoked during to validate and convert a string
representation.
[para] It has to verify that [arg x] is a legal string representation
for the parameter instance [arg p], and return the associated internal
representation.

[manpage_begin [vset PROJECT]_vtypes [vset MAN_SECTION] [vset VERSION]]
[include parts/module.inc]
[require cmdr::validate]
[titledesc [vset TITLE_DEV_VT]]
[description]
[include parts/welcome.inc]
This document describes the API expected of [term {validation types}]
to make them usable within the [vset PTITLE] framework, and how to
write a custom validation type.
[para] Readers interested in the standard validation types of the
framework should read [term [vset TITLE_VALIDATE]].
[section Background]
Validation types are [vset PTITLE]'s answer to the necessity of moving
................................................................................
[para] Because of the same necessity all parameters must have a
validation type assigned to them, and the framework will choose which,
if the user did not. This choice is made per the six rules below and
always returns one of the builtins described in [term [vset TITLE_VALIDATE]].
[list_begin enumerated]
[enum] Use [const identity] if a [cmd generate] callback is specified.
[enum] Use [const boolean] if no [cmd default] is specified and the parameter is an [term option].
[enum] Use [const identity] if no [cmd default] is specified and the parameter is an [term input].
[enum] Use [const boolean] if the specified [cmd default] value is a Tcl boolean.
[enum] Use [const integer] if the specified [cmd default] value is a Tcl integer.
[enum] Use [const identity] as fallback of last resort.
[list_end]
[para] The general concept of [term {validation types}] was taken frompackage [package snit], and modified to suit [vset PTITLE].
Where [package snit]'s types expect only a single method to validate
the input we expect all types to support an ensemble of [emph four]
methods.One for the basic validation and transformation of the string, anotherfor the release of any internal representation so generated, plus two
more for delivery of a default representation and support for command
line completion.
The details (method names, signatures, etc.) can be found in section
[sectref API] below.
[para] As an example the implementation of the standard boolean
validation type is shown in section [sectref Example].
[para] It should be noted that while [package snit]'s validation types
in principle allow for the transformation of input into a disparate
internal representation, they never went so far as to allow complex
representations which might require the release of resources after
use.
[para] The [cmd validate] and [cmd release] methods are primarily used
during either [term Completion] or [term Execution] phases, depending
on the chosen deferal state.
They may also be used during the [term Parsing] phase, for optional
[term inputs] under the [cmd test]-regime].
[para] The [cmd complete] method will be used whereever the system
activates an interactive command line shell where arguments may be
assigned to parameters.
[para] The [cmd default] method on the other hand can expect to be
invoked during the [term Dispatch] phase, as part of the system's
declaration processing, if not preempted by [cmd default] and
[cmd generate] declarations for the parameter.
Note here that the [cmd default] method has the same signature as aparamete's [cmd generate] callback and can be used as such.
This is actually needed and useful when the default internal
representation for a validation type cannot be expressed as a fixed
value and its creation while parsing the specification itself is tooearly.
We can still use the validation type for its generation, by hooking it
explicitly into [cmd generate] to change the timing of its invokation.
[section API]
In the descriptions below the [cmd <v-type>] is a placeholder for the
actual command prefix, most often a main command, of the validation
type.
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd <v-type>] [method complete] [arg p] [arg x]]
This method is invoked during command completion done by the framework.
[para] It has to return the list of legal string representations for
the type and parameter instance [arg p] which have the incomplete word
[arg x] as their prefix.
................................................................................
custom type may have need for access to the context of the completion.
[arg_def string x]
The string value to complete.
[list_end]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd <v-type>] [method default] [arg p]]
This method is invoked when the framework has to determine the
internal representation of a parameter which has no user-specified
string representation.
[para] It has to return the default internal representation for
the type and parameter instance [arg p].
................................................................................
do not make use of it a custom type may have need for access to the
context.
[arg_def string x]
The string value to complete.
[list_end]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd <v-type>] [method release] [arg p] [arg x]]
This method is invoked when the framework has to get rid of an
internal representation for a parameter.
[para] It has to release any resources associated with the internal
representation [arg x] of parameter instance [arg p].
................................................................................
of the completion.
[arg_def string x]
The internal representation to release.
[list_end]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd <v-type>] [method validate] [arg p] [arg x]]
This method is invoked during to validate and convert a string
representation.
[para] It has to verify that [arg x] is a legal string representation
for the parameter instance [arg p], and return the associated internal
representation.

[para] The conceptual model underneath the command hierarchy is that
of a tree.
[para] The inner nodes of the tree represent command ensembles, here
called "officer"s. Each officer knows one or more commands, and
delegates actual execution to their respective specification, whichmay be another officer, or a private.
[para] The leaf nodes of the tree represent the individual commands,
here called "private"s. Each private is responsible for a single
action, and knows how to perform it and the parameters used toconfigure that action at runtime.
[para] The same model is graphically presented in the
Entity-Relationship-Diagram below.
[image erd]
[para] The "Actor" in that diagram is the common base class for the
ensembles and commands and not directly relevant to users.
[para] The "Config" on the other hand is the second interface seen by
the user, as the sole argument to the action command prefix of
[cmd private] (See section [sectref Officer]).
This container holds all the declared parameters of the command the
action is invoked for, and provides easy access to them through its
methods (see package [package cmdr::config]) at the time of execution.

[para] The conceptual model underneath the command hierarchy is that
of a tree.
[para] The inner nodes of the tree represent command ensembles, here
called [term officer]s. Each officer knows one or more commands toperform, and delegates actual execution to their respective
specification, which may be another [term officer], or a [term private].
[para] The leaf nodes of the tree represent the individual commands,
here called [term private]s.Each [term private] is responsible for a single action and knows howto perform it, and the set of [term parameter]s used to configure that
action at runtime.
[para] The same model is graphically presented in the
Entity-Relationship-Diagram below.
[image erd]
[para] The [term actor] in that diagram is the common base class for the
ensembles and commands and not directly relevant to users.
[para] The [term config] on the other hand is the second interface
seen by the user, as the sole argument to the action command prefix of
[cmd private]. See [term [vset TITLE_DSL_OFFICER]] for the details.
This container, an instance of [package cmdr::config], holds all the
declared parameters of the command the action is invoked for, and
provides easy access to them through its methods at the time ofexecution.

[comment { No tables in doctools, using an example to get a tabular formatting. }][comment { TODO doctools: table markup }][comment { TODO doctools: named TOCs for commands - embedded small TOCs}][example {alias <name> = <name'>... Declare an alternate name for a command path.alias <name> Declare an alternate name for the previous command.common <name> <script> Declare a named shared code block.default Set last command as default.description <text> Set help text for the current ensemble.ehandler <cmdprefix> Execution Interposition.officer <name> <script> Declare a nested ensemble = sub-officerprivate <name> <script> <cmdprefix> Declare a simple command = privateundocumented Hide ensemble from help.}]
[list_begin definitions]
[def "[cmd alias] [arg name] [const =] [arg name']..."]
[def "[cmd alias] [arg name]"]
This is a structuring command, for the command hierarchy. Its main
uses are the creation of alternate command names, and of shortcuts
through the command hierarchy.
[para] For example, stackato's command specification for alias management ismore like [sectref {Basic setup, command nesting}] and uses shortcutssimilar to what is shown in--TODO--(example ls-alias2)-- to provide the look of a flat namespace.
[para] In the first form the [arg name] is given the explicit path to
the command it is an alias for. In the second form it implicitly
refers to the immediately preceding officer or private.
Note that "immediately" is interpreted at the current level. The
system is [emph not] looking into a nested specification for its last
command.
[def "[cmd common] [arg name] [arg text]"]
This is another structuring command, for structuring the specification
itself instead of the command tree it declares.
[para] It creates named values, usually code blocks, which can be
shared between specifications. Note that while each block is visible
in the current officer and its subordinates, parents and siblings have
no access.
[para] An example of such a block would be
[example {
common *all* {
option debug {
Activate client internal tracing.
................................................................................
foreach t $tags { debug on $t }
}]
}
}
}]
This example defines an option to access the subsystem for debug
narative (See package [package Tcllib]).
The example is actually special, as the block named [const *all*] is
reserved by the framework. This block, if defined, is automatically
included at the front of all "private" specifications, i.e. shared
across all the specified commands underneath this officer. A veryimportant trait for the option in the example, as it makes the debug
setup available to all commands without having to explicitly include
the block, and possibly forgetting such.
[para] Generally speaking, the framework reserves all blocks whose
name begins with a star, i.e [const *], for its own use.
[def "[cmd default]"]
This command sets up a special kind of alias. The last "private" or"officer" is set as the default command to use at runtime.
This means that if during "Dispatch" the currently processed word does
not match any of the commands known to this officer this default is
used. If no default is specified an error will be thrown instead.
[def "[cmd description] [arg text]"]
This command declares the help text of the officer.
[def "[cmd ehandler] [arg cmdprefix]"]
This is an advanced command which should normally only be specified at
the top of the whole hierarchy (from which its value will
automatically propagate to all subordinates).
[para] At runtime the framework will call the specified command prefix
with a single argument, a script whose execution is equivalent to the
phases "Parsing", "Completion", and "Execution" of the framework, as
described in section --TODO--(sectref:flow/phases)--. The handler [emph must]
call this script, and can perform any application-specific actions
before and after.
[para] This handler's main uses are two-fold:
[list_begin enumerated]
[enum] Capture and hande application-specific errors which should not
abort the application, or shown as Tcl stacktrace.
[enum] Cleanup of application-specific transient settings the
parameter callbacks and/or command implementations may have set during
their execution. This is especially important if the interactive
command line shells of the framework are active. Without such ahandler and its bespoke cleanup code transient settings will leakbetween multiple commands run from such a shell, something which is
definitely not wanted.
[list_end]
[def "[cmd officer] [arg name] [arg script]"]
This command creates a named subordinate officer with its
specification [arg script] of officer commands as described here.
[def "[cmd private] [arg name] [arg script] [arg cmdprefix]"]
This command creates a named subordinate private with its
specification [arg script] of private commands as described in thefollowing section, and a command prefix to invoke when it is chosen.
[para] This command prefix is called with a single argument, the
[package cmdr::config] instance holding the parameters of the private.
--TODO--(ref:backend-example-code)--
[def "[cmd undocumented]"]
Use of this command influences the generation of help, excluding allofficers having this marker (and their subordinates) from thehelp. Note that subordinates reachable through aliases may be
included, under the alias name, if not explicitly excluded themselves.
[list_end]

[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd alias] [arg name] [const =] [arg name']...]
[call [cmd alias] [arg name]]
This is a structuring command, for the command hierarchy. Its main
uses are the creation of alternate command names, and of shortcuts
through the command hierarchy.
[para] For example, [syscmd stackato]'s command specification for
alias management is written using deep nesting and uses aliases to
provide the look of a flat namespace to application users.
[para] In the first form the [arg name] is given the explicit path to
the actor the name is an alias for.In the second form the alias implicitly refers to the immediately
preceding [term officer] or [term private].
Note that "immediately" is interpreted at the current level. The
system is [emph not] looking into a nested specification for its last
command.
[list_begin arguments][arg_def string name]The name of the alias.[arg_def string name'...]The path to the actor, as list of names.[list_end][comment {- - -- --- ----- -------- -------------}]
[call [cmd common] [arg name] [arg text]]
This is another structuring command, for structuring the specification
itself instead of the command tree it declares.
[para] It creates named values, usually code blocks, which can be
shared between specifications. Note that while each block is visible
in the current [term officer] and its subordinates, parents and
siblings have no access.
[para] An example of such a block would be
[example {
common *all* {
option debug {
Activate client internal tracing.
................................................................................
foreach t $tags { debug on $t }
}]
}
}
}]
This example defines an option to access the subsystem for debug
narative (See package [package Tcllib]).
The example is actually special, as the block named [const *all*] is
reserved by the framework.
This block, if defined, is automatically included at the front of all[term private] specifications, i.e. shared across all the privatesspecified underneath this [term officer]. A very important trait forthe [term option] in the example, as it makes the debug setupavailable to all privates without having to explicitly include the
block, and possibly forgetting such.
[para] Generally speaking, the framework reserves all blocks whose
name begins with a star, i.e [const *], for its own use.
[list_begin arguments][arg_def string name]The name of the common block.[arg_def string text]The text of the block.[list_end][comment {- - -- --- ----- -------- -------------}]
[call [cmd default]]
This command sets up a special kind of alias.
The last [term private] or [term officer] is set as the default
command to use at runtime.
This means that if during "Dispatch" phase the currently processed
word does not match any of the commands known to this [term officer]this default is used. If no default is specified an error will be
thrown instead.[comment {- - -- --- ----- -------- -------------}]
[call [cmd description] [arg text]]
This command declares the help text of the [term officer].
[comment {- - -- --- ----- -------- -------------}]
[call [cmd ehandler] [arg cmdprefix]]
This is an advanced command which should normally only be specified at
the top of the whole hierarchy (from which its value will
automatically propagate to all subordinates).
[para] At runtime the framework will call the specified command prefix
with a single argument, a script whose execution is equivalent to the
phases "Parsing", "Completion", and "Execution" of the framework, as
described in --TODO--(sectref:flow/phases)--. The handler [emph must]
call this script, and can perform any application-specific actions
before and after.
[para] This handler's main uses are two-fold:
[list_begin enumerated]
[enum] Capture and hande application-specific errors which should not
abort the application, nor shown as Tcl stacktrace.
[enum] Cleanup of application-specific transient state the
[term parameter] callbacks (See [term [vset TITLE_DSL_PARAMETER]])and/or actions may have set during their execution.
This is especially important if the interactive command line shells ofthe framework are enabled. Without such a handler and its bespoke
cleanup code transient state [emph will] leak between multiple
commands run from such a shell, something which is definitely not
wanted.
[list_end]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd officer] [arg name] [arg script]]
This command creates a named subordinate [term officer] with its
specification [arg script] of officer commands as described here.
[comment {- - -- --- ----- -------- -------------}]
[call [cmd private] [arg name] [arg script] [arg cmdprefix]]
This command creates a named subordinate [term private] with its
specification [arg script] of private commands
(See [term [vset TITLE_DSL_PRIVATE]]), and a command prefix to invoke
when it is chosen.
[para] This command prefix is called with a single argument, the
[package cmdr::config] instance holding the [term parameter]s of theprivate.
--TODO--(ref:backend-example-code)--
[comment {- - -- --- ----- -------- -------------}]
[call [cmd undocumented]]
This command excludes the [term officer] (and its subordinates) fromthe generated help.
Note that subordinates reachable through aliases may be included,
under the alias name, if they are not explicitly excluded themselves.
[list_end]

Of the four callbacks supported by parameters the first two,
"generate" and "validate" have been described already, in the sections--TODO--\ref{para/reps} about representations and--TODO--\ref{para/vtype} about validation types, respectively.
[para] This section explains the commonalities between the callbacks
in general, and the last two, for notifications about state changes in
detail.
[para] All callbacks are treated as command prefixes, not
scripts.
There are no placeholder substitutions, only arguments added to each
command prefix on invokation. This does not harm the generality of the
system, as complex scripts can be used via procedures or equivalents
(i.e. [cmd apply]).
[para] The two callbacks not yet described are the state-change
callbacks through which the framework can actively drive parts of the
application while processing the command line, whereas normally the
application drives access to parameters through their methods.
[list_begin definitions]
[def "[cmd when-complete] [arg cmdprefix]"]
This command declares the state-change callback to invoke when the
internal representation of the parameter is generated from the stringrepresentation, or the various ways of getting a default.
[para] The callback is invoked with two arguments, the
[package cmdr::parameter] instance of the parameter which changed, andits internal representation, in this order.
[def "[cmd when-set] [arg cmdprefix]"]
This command declares the state-change callback to invoke when the
string representation of the parameter is set during command line
parsing.
[para] The callback is invoked with two arguments, the
[package cmdr::parameter] instance of the parameter which changed, andits string representation, in this order.
[list_end]
Due to their nature these callbacks are invoked at runtime during
either parsing, completion," or execution. The details are shown in
the table below. The specification commands influencing the timing,
i.e. forcing the use in a specific phase are shown in the intersection
of callback and phase.
[example {
| Dispatch | Parsing | Completion | Execution
--------------------+----------+---------+-------------+-----------
validate (default) | * | | |
--------------------+----------+---------+-------------+-----------
validate (complete) | | * | immediate | defered

Of the four callbacks supported by parameters the first two,
[cmd generate] and [cmd validate] have been described already, in the
sections [sectref Representations] and [sectref Validation],
respectively.
[para] This section explains the commonalities between the callbacks
in general, and the last two, for notifications about state changes in
detail.
[para] All callbacks are treated as command prefixes, not scripts.
There are no placeholder substitutions, only arguments added to each
command prefix on invokation. This does not harm the generality of the
system, as complex scripts can be used via procedures or equivalents
(i.e. [cmd apply]).
[para] The two callbacks not yet described are the state-change
callbacks through which the framework can actively drive parts of the
application while processing the command line, whereas normally the
application drives access to parameters through their methods.
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd when-complete] [arg cmdprefix]]
This command declares the state-change callback to invoke when the
[term {internal representation}] of the [term parameter] is generatedfrom the [term {string representation}], or the various ways of
getting a default.
[para] The callback is invoked with two arguments, the
[package cmdr::parameter] instance of the changed [term parameter],and its [term {internal representation}], in this order.[comment {- - -- --- ----- -------- -------------}]
[call [cmd when-set] [arg cmdprefix]]
This command declares the state-change callback to invoke when the
[term {string representation}] of the [term parameter] is set duringcommand line parsing.
[para] The callback is invoked with two arguments, the
[package cmdr::parameter] instance of the changed [term parameter],and its [term {string representation}], in this order.
[list_end]
Due to their nature these callbacks are invoked at runtime during
either the [term Parsing], [term Completion], or [term Execution]phases.The details are shown in the table below. The specification commands
influencing the timing, i.e. forcing the use in a specific phase are
shown in the intersection of callback and phase.
[example {
| Dispatch | Parsing | Completion | Execution
--------------------+----------+---------+-------------+-----------
validate (default) | * | | |
--------------------+----------+---------+-------------+-----------
validate (complete) | | * | immediate | defered

[para] The general handling of a parameter is influenced by threecommands.
[list_begin definitions]
[def "[cmd optional]"]
This command marks the parameter as optional, i.e. as something the
user may skip on the command line, and the application supplying
sensible defaults. --TODO--(sectref:para/vtype)--During parsing the framework will then expend some effort to determine
whether an argument word should be assigned to the parameter, or not.
[para] This setting is only applicable to "inputs", as "options" are
optional by definition, and "state" is hidden.
[def "[cmd test]"]
This command is related to the above, switching from the standardregime for acceptance based on counting and thresholds to a differentone based on validation. The details are explained in section
--TODO--(sectref:flow/parsing,flow/optional)--.
[def "[cmd undocumented]"]
Like "officers" and "privates" parameters can be hidden from thegenerated help. This is the command for doing so, the same as for thefirst two.
[para] The main use case is the hiding of options giving an
application developer access to the internals of their application,
something a regular user has no need of, and doesn't have to know
about.
[list_end]

[para] The general handling of a [term parameter] is influenced by
three commands:
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd optional]]
This command marks the parameter as [term optional], i.e. as something
the user may skip on the command line, with the application supplying
sensible defaults (See section [sectref Representations]).This causes the framework to expend some effort in the [term Parsing]phase to determine whether an argument word should be assigned to the
parameter, or not.
[para] This setting is only applicable to [term input]s, as[term option]s are optional by definition, and [term state] is hidden.
[comment {- - -- --- ----- -------- -------------}]
[call [cmd test]]
This command is related to the above, switching the runtime from the
standard regime for acceptance (based on counting and thresholds) to adifferent regime based on validation.
The details are explained in --TODO--(sectref:flow/parsing,flow/optional)--.
[comment {- - -- --- ----- -------- -------------}]
[call [cmd undocumented]]
This command excludes the [term parameter] from the generated help.
[para] Its main use case is the hiding of [term option]s giving an
application developer access to the internals of their application,
something a regular user has no need of, and doesn't have to know
about.
[list_end]

[para] We have two commands to influence the visible naming of all
parameters.
[para] As background, all parameters are named for proper
identification within the framework and other Tcl code, i.e. the
various callbacks, including a "private"s action. This "system name"
has to be unique within the "private" a parameter belongs to. Beyond
that however the visible parameters have to be identified within helptexts, and, in case of "options", for detection during "Parsing". That
is the visible naming, seen by a user of any application whose command
line processing is based on the [vset PTITLE] framework.
[list_begin definitions]
[def "[cmd label] [arg text]"]
This command declares the visible name, if different from the systemname used as the default. Note that in most cases this default is good
enough, obviating the need for this command.
[para] The only use case seen so far is when two semantically
equivalent input and option parameters clash, requiring differentinternal names due to the requirement for uniqueness, yet also the
same visible name and flag within the help to highlight their
connection and equivalence.
[def "[cmd alias] [arg name]"]
For option parameters the "label" command and its default specifiesthe name of the primary flag recognized during parsing. If that is notenough for a specific option this command allows the specification of
any number additional flags to be recognized.
[para] Note however that the framework automatically recognizes not
only the specified flags, but also all unique prefixes, obviating the
need for this command in many cases.
[list_end]

[para] We have two commands to influence the visible naming of all
[term parameter]s.
[para] As background, all [term parameter]s are named, to properly
identify them within the framework and other Tcl code, i.e. in the
various callbacks and the [term private]'s action.This [term {system name}] has to be unique within the [term private] a[term parameter] belongs to.Beyond that however the visible (i.e. non-term state])[term parameter]s have to be identified by users within help texts,and, in the case of [term option]s, for detection during the[term Parsing] phase.That is the visible naming, seen by a user of any application whose
command line processing is based on the [vset PTITLE] framework.
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd label] [arg text]]
This command declares the [term parameter]'s visible name, if
different from the [term {system name}] used as the default. Note that
in most cases this default is good enough, obviating the need for this
command.
[para] The only use case seen so far is when two semantically
equivalent [term input] and [term option] [term parameter]s clash,forcing the use of different system names due to the requirement for
their uniqueness, yet also use the same visible name and flag within
the help to highlight their connection and equivalence.
[comment {- - -- --- ----- -------- -------------}]
[call [cmd alias] [arg name]]
For [term option]s the [cmd label] command and its default specifiesthe name of the [term {primary flag}] recognized during the[term Parsing] phase.If that is not enough for a specific [term option] this command allowsthe specification of any number additional flags to be recognized.
[para] Note however that the framework automatically recognizes not
only the specified flag(s), but also all their unique prefixes,obviating the need for this command in many cases.
[list_end]

[para] An important concept of parameters is something taken up from
Tcl itself.
The differentation between string and internal representations.
Where Tcl uses internal representations to speed up its execution here
this separation is that of between the information delivered to the
application by a user, and the application-specific data structures
behind them.
[para] All parameters will have an internal representation.
This is usually derived from the string representation provided by the
user.
The details of that process are explained in section
--TODO--(sectref:para/vtype)--about validation types.
However we have cases where the user cannot specify a string
representation ("states"), or is allowed to choose not to (optional"inputs", "options").
For these cases three specification commands are made available
enabling us to programmatically choose the internal representation.
[list_begin definitions]
[def "[cmd default] [arg value]"]
This command provides a constant value for the internal
representation.
[def "[cmd generate] [arg cmdprefix]"]
This command provides a callback to compute the internal
representation at runtime. This is useful if the default is something
which cannot be captured as a fixed value, for example a handle to
some resource, or a dynamically created object.
[para] The command prefix is invoked with a single argument, the
[package cmdr::parameter] instance for which to generate the internal
representation.
[list_end]
[para] The commands "default" and "generate" exclude each other,
i.e. only of them can be specified.
If neither are specified, and we need a default (see the cases
above) a default is chosen per the two rules below:
[list_begin enumerated]
[enum] Use the empty string for a "list" parameter.
[enum] Use the default value supplied by the chosen validation type (See section --TODO--(sectref:para/vtype)--).
[list_end]
[list_begin definitions]
[def "[cmd interact] [opt [arg prompt]]"]
This command actually does not specify an internal representation, but
activates another method for the user to specify a string value forthe parameter, outside of the command line.
As such it has priority over either "default" and "generate," and can
be specified with either. A parameter marked with it will
interactively ask the user for a value if none was specified on the
command line.
[para] The default [arg prompt] is derived from the system name.
[list_end]
[para] To recapitulate:
[list_begin enumerated]
[enum] A string representation specified on the command line has the
highest priority and goes through the chosen validation type to get the associated internal representation.
[enum] If activated via "interact" a small shell is run asking the
user for a value (or more, as per "list", see below). The result goes through the chosen validation type to get the associated internal representation.
[enum] After that the internal representation is either the declared "default," or the result of invoking the "generate" callback. As internal representations they are [emph not] run through the chosen validation type.
[list_end]
[list_begin definitions]
[def "[cmd list]"]
This command is used to mark parameters whose string and thus internalvalue should be treated as a list. By default all parameters are scalar.
[para] This affects the handling of the parameter during parsing, by"interact" above, and the use of the validation type. The last two ask
for multiple values, and feed the elements of the string value
separately through validation instead of just the string value in one.
During parsing treatment of "options" changes from keeping only the
last assigned value to accumulation of all values. Similarly alist-"input" takes all remaining words on the command line for itself
instead of just the current word. Because of this list-"inputs" are
only allowed as the last parameter of a "private."
[list_end]
[para] The last two specification commands dealing with the
representations control when the internal representation is created.
[list_begin definitions]
[def "[cmd defered]"]
This command marks a parameter as defered, with the internalrepresentation computed on first access to its value. This is thedefault for "state" parameters.
[def "[cmd immediate]"]
This command marks a parameter as immediate, with the internalrepresentation computed in the "Completion" phase. This is the defaultfor "input" and "option" parameters.
[list_end]

[para] An important concept of [term parameter]s is something taken up
from Tcl itself.
The differentation between [term string] and [term {internal representations}].
Where Tcl uses [term {internal representations}] to speed up itsexecution here this separation is that of between the information
delivered to the application by a user, and the application-specific
data structures behind them.
[para] All [term parameter]s will have an [term {internal representation}].
This is usually derived from the [term {string representation}]provided by the user.
The details of that process are explained in section [sectref Validation].
However we have cases where the user cannot specify a string
representation ([term state]s), or is allowed to choose not to
(optional [term input]s, [term option]s).
For these cases three specification commands are made available
enabling us to programmatically choose the internal representation.
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd default] [arg value]]
This command specifies a constant default value for the internal
representation.
[comment {- - -- --- ----- -------- -------------}]
[call [cmd generate] [arg cmdprefix]]
This command specifies a callback to compute the default internal
representation at runtime. This is useful if the default is something
which cannot be captured as a fixed value. An example would be ahandle to some resource, or a dynamically created object.
[para] The command prefix is invoked with a single argument, the
[package cmdr::parameter] instance for which to generate the internal
representation.
[list_end]
[para] The commands [cmd default] and [cmd generate] exclude eachother, i.e. only of them can be specified, but not both.
If neither are specified, and we need a default (see the cases above)then a default is chosen by the framework itself, as per the two rulesbelow:
[list_begin enumerated]
[enum] Use the empty string for a [cmd list] parameter.
[enum] Use the default value supplied by the chosen
[term {validation type}] (See section [sectref Validation]).
[list_end]
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd interact] [opt [arg prompt]]]
This command actually does not specify an
[term {internal representation}], but activates another method for the
user to specify the [term {string representation}] of the[term parameter], outside of the command line.
As such it has priority over either [cmd default] and [cmd generate],and can be specified with either. A [term parameter] marked with itwill interactively ask the user for a value if none was specified on
the command line.
[para] The default for the [arg prompt] is derived from the
[term parameter]'s [term {system name}].
[list_end]
[para] To recapitulate:
[list_begin enumerated]
[enum] A [term {string representation}] specified on the command line
has the highest priority and goes through the chosen
[term {validation type}] to get the associated[term {internal representation}].
[enum] If activated via [cmd interact] a small shell is run asking the
user for a value (or more, as per [cmd list], see below). The result
goes through the chosen [term {validation type}] to get the associated[term {internal representation}].
[enum] After that the [term {internal representation}] is either thedeclared [cmd default] value, or the result of invoking the
[cmd generate] callback.As [term {internal representation}]s the resulting values are[emph not] run through the chosen [term {validation type}].
[list_end]
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd list]]
This command marks the [term parameter] as a list. In other words, its[term string] and [term {internal representation}] is actually a listof such, instead of a single value.
By default all parameters are scalar.
[para] This affects the handling of the parameter by the[term Parsing] phase, by [cmd interact] above, and the use of the[term {validation type}].The last two ask for multiple values, and feed the elements of the
[term {string representation}] separately through validation instead
of just the string value in one.In the [term Parsing] phase treatment of [term option]s changes fromkeeping only the last assigned value to the accumulation of allvalues.Similarly a list-[term input] takes all the remaining words on thecommand line for itself instead of just the current word. Because of
this list-[term inputs] are only allowed as the last [term parameter]of a [term private].
[list_end]
[para] The last two specification commands dealing with the
representations control [emph when] the[term {internal representation}] is created.
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd defered]]
This command marks a [term parameter] as [term defered], causing its[term {internal representation}] to be computed on first access to its
value. This is the default for [term state] parameters.[comment {- - -- --- ----- -------- -------------}]
[call [cmd immediate]]
This command marks a [term parameter] as [term immediate], causing its[term {internal representation}] to be computed in the[term Completion] phase.This is the default for [term input] and [term option] parameters.
[list_end]

[para] The answer to the necessity of moving between the string andinternal representations described in the previous section are the
validation types. Given a string representation they either return theassociated internal representation or raise an error, signaling thatthe input was illegal. This part of their work, the verification of
the legality of the input string gave them their name.
[comment {--TODO--(textblock shared with cmdr-vtypes.man)}]
[para] The general concept of validation types was taken from
[package snit], and modified to suit [vset PTITLE]. Where snit's types
expect only a single method to validate the input [vset PTITLE]
expects all types to support an ensemble of [emph four] methods, one
for the basic validation and transformation of the input, another for
the release of any internal representation so generated, plus delivery
of a default representation and support for command line completion.
[list_begin definitions]
[def "[cmd validate] [arg cmdprefix]"]
This command specifies a validation type for the parameter, in the
form of a command prefix.
The set of methods this callback has to support, their signatures,
etc. are all explained in [term [vset TITLE_DEV_VT]]. This document
contains the implementation of the standard boolean validation type as
an example as well.
[para] Because of the same necessity all parameters must have a
validation type assigned to them, and the system will choose which, if
the user did not. This choice is made per the six rules below and
always returns one of the standard types implemented in package
[package cmdr::validate].
[list_begin enumerated]
[enum] Use "identity" if a "generate" callback is specified.
[enum] Use "boolean" if no "default" is specified and the parameter is an option.
[enum] Use "identity" if no "default" is specified and the parameter is an input.
[enum] Use "boolean" if the specified "default" value is a Tcl boolean.
[enum] Use "integer" if the specified "default" value is a Tcl integer.
[enum] Use "identity" as fallback of last resort.
[list_end]
[def "[cmd presence]"]
This command is best discussed as part of the wider area of "boolean"options, i.e. options with validation type "boolean" assigned tothem. These have associated special behaviours, both in the handling
of the specification, and during parsing.
[para] First, normal boolean options. They have automatic aliases
declared for them, derived from their primary flag. An option named
"foo" will have an alias of "no-foo", and the reverse. During parsing
the "foo" and "no-foo" flags have inverse semantics, and both are
allowed to occur without option argument following the flag. This is
in contrast to all other options which must have such an argument. The
parser essentially uses the validation type to decide if the word
after the flag is a proper boolean value, or not, i.e. an argument toassign to the parameter, or not.
[para] Now "presence" declares a variant of the above, a boolean
option without the automatic aliases, and [emph never] taking anargument during parsing. Its mere [emph presence] on the command line
will set its parameter. Their default value is consequently fixed to
[const false] as well.
[list_end]

[para] The answer to the necessity of moving between the [term string]and [term {internal representations}] described in the previous
section are the [term {validation types}].Given a [term {string representation}] they either return theassociated [term {internal representation}] or raise an error,signaling that the string was illegal. This part of their work, the
verification of the legality of the input string gave them their name.
[comment {--TODO--(textblock shared with cmdr-vtypes.man)}]
[para] The general concept of [term {validation types}] was taken from
[package snit], and modified to suit [vset PTITLE].
Where snit's types expect only a single method to validate the input
[vset PTITLE] expects all types to support an ensemble of [emph four]
methods, one for the basic validation and transformation of the input,
another for the release of any internal representation so generated,
plus delivery of a default representation and support for command line
completion.
[list_begin definitions]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd validate] [arg cmdprefix]]
This command specifies a [term {validation type}] for the
[term parameter], in the form of a command prefix (or the name of oneof the builtin types, see package [package cmdr::validate]).
The set of methods this callback has to support, their signatures,
etc. are all explained in [term [vset TITLE_DEV_VT]]. This document
contains the implementation of the standard boolean validation type as
an example as well.
[para] Because of the same necessity all [term parameter]s must have a
[term {validation type}] assigned to them, and the system will choose
which, if the user did not. This choice is made as per the six rulesbelow and always returns one of the standard types implemented bypackage [package cmdr::validate].
[list_begin enumerated]
[enum] Use [const identity] if a [cmd generate] callback is specified.
[enum] Use [const boolean] if no [cmd default] is specified and the parameter is an [term option].
[enum] Use [const identity] if no [cmd default] is specified and the parameter is an [term input].
[enum] Use [const boolean] if the specified [cmd default] value is a Tcl boolean.
[enum] Use [const integer] if the specified [cmd default] value is a Tcl integer.
[enum] Use [const identity] as fallback of last resort.
[list_end]
[comment {- - -- --- ----- -------- -------------}]
[call [cmd presence]]
This command is best discussed as part of the wider area of
[term boolean] [term option]s, i.e. [term option]s with the standard[term {validation type}] [const boolean] assigned to them. These have
associated special behaviours, both in the handling of the
specification, and in the [term Parsing] phase.
[para] First, normal boolean options.
They have automatic aliases declared for them, derived from their
primary flag.An option named "foo" will have an alias of "no-foo", and the
reverse.In the [term Parsing] phase the "foo" and "no-foo" flags have inverse
semantics, and both are allowed to occur without option argument
following the flag.This is in contrast to all other [term option]s which must have suchan argument. The parser essentially uses the [term {validation type}]to decide if the word after the flag is a proper boolean value, or
not, i.e. an argument to assign to the [term parameter], or not.
[para] Now [cmd presence] declares a variant of the above, a boolean
option [emph without] the automatic aliases, and [emph never] taking
an argument during parsing.
Its mere [emph presence] on the command line will set its[term parameter].Their [cmd default] value is consequently fixed to [const false] as
well.
[list_end]

[para] The [term parameter]s of [term private]s are the heart of the
system, providing the space needed to transfer command arguments totheir implementations, and having the most attributes controlling
their behaviour.
[para] This complexity is strongly mitigated by the use of sensible
defaults for each of the three possible kinds of parameter, i.e.
positional [term input]s, named [term option]s", and [term state]hidden from the command line.
[para] Each kind has its own construction command in the language for
[term private]s (See [term [vset TITLE_DSL_PRIVATE]]) which specifiesthe common information which cannot have defaults, i.e.
[list_begin enumerated]
[enum] the name identifying it to the system,
[enum] the help text describing it in informal speech, and, of course,
[enum] the parameter specification itself, using the commands of this section.
[list_end]
[para][subsection Naming]
[include dsl_para_naming.inc]
[para][subsection {General control}]
[include dsl_para_general.inc]
[para][subsection Representations]
[include dsl_para_reps.inc]
[para][subsection Validation][include dsl_para_validation.inc][para][subsection Signaling][include dsl_para_callbacks.inc]

[para] The specification of simple commands, i.e. "privates" is quiteeasy, with only seven commands (see the table below). The importantparts are found in the parameter specifications, explained in the nextsection.[comment { No tables in doctools, using an example to get a tabular formatting. }][comment { TODO doctools: table markup }][comment { TODO doctools: named TOCs for commands - embedded small TOCs}][example {description <text> Set help text for command.input <name> <help> <script> Declare a positional parameter.interactive Allow interactive shell.option <name> <help> <script> Declare a named parameter.state <name> <help> <script> Declare a hidden parameter.undocumented Hide command from help.use <name> Execute the named "common" block here.}][list_begin definitions][def "[cmd description] [arg text]"]Like the equivalent command for [sectref Officers] this commanddeclares the help text for the private.[def "[cmd input] [arg name] [arg help] [arg script]"]This command adds an "input" (positional) parameter to the "private",with description [arg help] and its specification [arg script] ofparameter commands as described in the following section.[def "[cmd interactive]"]This command influences the runtime. By default the only interactivecommand line shells are associated with the officers. Setting thismarker activates such a shell for the private, to be invoked whenrequired parameters do not have a value.[para] The global command [cmd {cmdr::config interactive}] in package[package cmdr::config] can be used to globally activate this type ofshell for all "privates".[def "[cmd option] [arg name] [arg help] [arg script]"]This command adds an "option" (named) parameter to the "private", withdescription [arg help] and its specification [arg script] of parametercommands as described in the following section.[def "[cmd state] [arg name] [arg help] [arg script]"]This command adds a "state" (hidden) parameter to the "private", withdescription [arg help] and its specification [arg script] of parametercommands as described in the following section.[def "[cmd undocumented]"]Like the equivalent command for [sectref Officers] use of this commandinfluences the generation of help, excluding all privates having thismarker from it.[def "[cmd use] [arg name]"]This command is the counterpart to [cmd common] of [sectref Officers].It inserts the named block into the specification, executing it. Assuch it expects the contents to be a script of private commands asdescribed in this section.[list_end]

..
.de UL
\\$1\l'|0\(ul'\\$2
..
.TH "cmdr_dsl" n 0 doc "Cmdr, a framework for command line parsing and dispatch"
.BS
.SH NAME
cmdr_dsl \- Cmdr - Specification Language
.SH DESCRIPTION
.PP
Welcome to the Cmdr project, written by Andreas Kupries\&.
.PP
For availability please read \fICmdr - How To Get The Sources\fR\&.
.PP
This document is for users of the cmdr framework\&. It describes the
domain-specific language for the specification of command hierarchies
with commands and their parameters (options, and inputs)\&.
.SH "INTRODUCTORY EXAMPLES"
Instead of immediately diving into the full syntax of the
specification language first a few examples to demonstrate the general
look and feel, plus basic features\&.
.SS "BASIC SETUP, PRIVATE WITH INPUTS"
.PP
This example specifies a command line providing 3 commands for
the management of command aliases\&.
This is actually a slice of \fBstackato\fR's interface, reduced and
modified to fit here\&.
While it does not have the necessary backend procedures required to
actually run the commands, it is enough to demonstrate basic features,
................................................................................
.CE
.PP
At the bottom of the example, just above we can also see the
very simple Tcl command which invokes the command line processing for
a list of words, here coming from \fB$argv\fR, i\&.e\&. the application's
command line\&.
.SS "BASIC SETUP, COMMAND NESTING"
.PP
The decoupling of command names from their implementations seen
in the previous example makes it easy to re-arrange and re-label the
user visible commands without having to touch any other part of the
code\&.
.PP
This is demonstrated in the example below, moving the 3
................................................................................
\&.\&.\&.
.CE
.SH "LANGUAGE REFERENCE"
With the examples behind us we can now go and specify the entire
specification language\&. If you have skipped here on first reading,
ignoring the examples, please go back and read them first\&.
.SS GENERAL
.PP
The conceptual model underneath the command hierarchy is that
of a tree\&.
.PP
The inner nodes of the tree represent command ensembles, here
called "officer"s\&. Each officer knows one or more commands, and
delegates actual execution to their respective specification, which
may be another officer, or a private\&.
.PP
The leaf nodes of the tree represent the individual commands,
here called "private"s\&. Each private is responsible for a single
action, and knows how to perform it and the parameters used toconfigure that action at runtime\&.
.PP
The same model is graphically presented in the
Entity-Relationship-Diagram below\&.
.PS
.nf
is-a is-a
/-1:1-> actor <-1:1-\\
................................................................................
\\--/
1:(0-n)
has
.fi
.PE
.PP
The "Actor" in that diagram is the common base class for the
ensembles and commands and not directly relevant to users\&.
.PP
The "Config" on the other hand is the second interface seen by
the user, as the sole argument to the action command prefix of
\fBprivate\fR (See section \fBOfficer\fR)\&.
This container holds all the declared parameters of the command the
action is invoked for, and provides easy access to them through its
methods (see package \fBcmdr::config\fR) at the time of execution\&..SS OFFICERS.CSalias <name> = <name'>\&.\&.\&. Declare an alternate name for a command path\&.alias <name> Declare an alternate name for the previous command\&.common <name> <script> Declare a named shared code block\&.default Set last command as default\&.description <text> Set help text for the current ensemble\&.ehandler <cmdprefix> Execution Interposition\&.officer <name> <script> Declare a nested ensemble = sub-officerprivate <name> <script> <cmdprefix> Declare a simple command = privateundocumented Hide ensemble from help\&..CE.TP\fBalias\fR \fIname\fR \fB=\fR \fIname'\fR\&.\&.\&..TP\fBalias\fR \fIname\fRThis is a structuring command, for the command hierarchy\&. Its mainuses are the creation of alternate command names, and of shortcutsthrough the command hierarchy\&..spFor example, stackato's command specification for alias management ismore like \fBBasic setup, command nesting\fR and uses shortcutssimilar to what is shown in--TODO--(example ls-alias2)-- to provide the look of a flat namespace\&..spIn the first form the \fIname\fR is given the explicit path tothe command it is an alias for\&. In the second form it implicitlyrefers to the immediately preceding officer or private\&.Note that "immediately" is interpreted at the current level\&. Thesystem is \fInot\fR looking into a nested specification for its lastcommand\&..TP\fBcommon\fR \fIname\fR \fItext\fRThis is another structuring command, for structuring the specificationitself instead of the command tree it declares\&..spIt creates named values, usually code blocks, which can beshared between specifications\&. Note that while each block is visiblein the current officer and its subordinates, parents and siblings haveno access\&..spAn example of such a block would be.CScommon *all* { option debug { Activate client internal tracing\&. } { undocumented list when-complete [lambda {p tags} { foreach t $tags { debug on $t } }] }}.CE.IPThis example defines an option to access the subsystem for debugnarative (See package \fBTcllib\fR)\&.The example is actually special, as the block named \fB*all*\fR isreserved by the framework\&. This block, if defined, is automaticallyincluded at the front of all "private" specifications, i\&.e\&. sharedacross all the specified commands underneath this officer\&. A veryimportant trait for the option in the example, as it makes the debugsetup available to all commands without having to explicitly includethe block, and possibly forgetting such\&..spGenerally speaking, the framework reserves all blocks whosename begins with a star, i\&.e \fB*\fR, for its own use\&..TP\fBdefault\fRThis command sets up a special kind of alias\&. The last "private" or"officer" is set as the default command to use at runtime\&.This means that if during "Dispatch" the currently processed word doesnot match any of the commands known to this officer this default isused\&. If no default is specified an error will be thrown instead\&..TP\fBdescription\fR \fItext\fRThis command declares the help text of the officer\&..TP\fBehandler\fR \fIcmdprefix\fRThis is an advanced command which should normally only be specified atthe top of the whole hierarchy (from which its value willautomatically propagate to all subordinates)\&..spAt runtime the framework will call the specified command prefixwith a single argument, a script whose execution is equivalent to thephases "Parsing", "Completion", and "Execution" of the framework, asdescribed in section --TODO--(sectref:flow/phases)--\&. The handler \fImust\fRcall this script, and can perform any application-specific actionsbefore and after\&..spThis handler's main uses are two-fold:.RS.IP [1]Capture and hande application-specific errors which should notabort the application, or shown as Tcl stacktrace\&..IP [2]Cleanup of application-specific transient settings theparameter callbacks and/or command implementations may have set duringtheir execution\&. This is especially important if the interactivecommand line shells of the framework are active\&. Without such ahandler and its bespoke cleanup code transient settings will leakbetween multiple commands run from such a shell, something which isdefinitely not wanted\&..RE.TP\fBofficer\fR \fIname\fR \fIscript\fRThis command creates a named subordinate officer with itsspecification \fIscript\fR of officer commands as described here\&..TP\fBprivate\fR \fIname\fR \fIscript\fR \fIcmdprefix\fRThis command creates a named subordinate private with itsspecification \fIscript\fR of private commands as described in thefollowing section, and a command prefix to invoke when it is chosen\&..spThis command prefix is called with a single argument, the\fBcmdr::config\fR instance holding the parameters of the private\&.--TODO--(ref:backend-example-code)--.TP\fBundocumented\fRUse of this command influences the generation of help, excluding allofficers having this marker (and their subordinates) from thehelp\&. Note that subordinates reachable through aliases may beincluded, under the alias name, if not explicitly excluded themselves\&..PP.SS PRIVATES.PPThe specification of simple commands, i\&.e\&. "privates" is quiteeasy, with only seven commands (see the table below)\&. The importantparts are found in the parameter specifications, explained in the nextsection\&.
.CSdescription <text> Set help text for command\&.input <name> <help> <script> Declare a positional parameter\&.interactive Allow interactive shell\&.option <name> <help> <script> Declare a named parameter\&.state <name> <help> <script> Declare a hidden parameter\&.undocumented Hide command from help\&.use <name> Execute the named "common" block here\&..CE.TP\fBdescription\fR \fItext\fRLike the equivalent command for \fBOfficers\fR this commanddeclares the help text for the private\&..TP\fBinput\fR \fIname\fR \fIhelp\fR \fIscript\fRThis command adds an "input" (positional) parameter to the "private",with description \fIhelp\fR and its specification \fIscript\fR ofparameter commands as described in the following section\&..TP\fBinteractive\fRThis command influences the runtime\&. By default the only interactivecommand line shells are associated with the officers\&. Setting thismarker activates such a shell for the private, to be invoked whenrequired parameters do not have a value\&..spThe global command \fBcmdr::config interactive\fR in package\fBcmdr::config\fR can be used to globally activate this type ofshell for all "privates"\&..TP\fBoption\fR \fIname\fR \fIhelp\fR \fIscript\fRThis command adds an "option" (named) parameter to the "private", withdescription \fIhelp\fR and its specification \fIscript\fR of parametercommands as described in the following section\&..TP\fBstate\fR \fIname\fR \fIhelp\fR \fIscript\fRThis command adds a "state" (hidden) parameter to the "private", withdescription \fIhelp\fR and its specification \fIscript\fR of parametercommands as described in the following section\&..TP\fBundocumented\fRLike the equivalent command for \fBOfficers\fR use of this commandinfluences the generation of help, excluding all privates having thismarker from it\&..TP\fBuse\fR \fIname\fRThis command is the counterpart to \fBcommon\fR of \fBOfficers\fR\&.It inserts the named block into the specification, executing it\&. Assuch it expects the contents to be a script of private commands asdescribed in this section\&.
.PP
.SS PARAMETERS.PPThe parameters of private commands are the heart of the system,providing the space needed to transfer the command arguments to theimplementations, and having the most attributes controlling theirbehaviour\&..PPThis complexity is mitigated strongly by the use of sensibledefaults for each of the three possible kinds of parameter, i\&.e\&.positional "inputs", named "options", and "state" hidden from thecommand line\&..PPEach kind has its own construction command in the DSL for\fBPrivates\fR which specifies the common information which cannothave defaults, i\&.e\&..IP [1]the name identifying it to the system,.IP [2]the help text describing it in informal speech, and, of course,.IP [3]the parameter specification itself, using the commands of this section\&..PP.CSalias <name> N Declare alternate flag for an option\&.default <value> R Set constant default value\&.defered R Defer calculation of the internal representation until demanded\&.generate <cmdprefix> R Set callback returning the default value\&.immediate R Complement of defered\&.interact ?<prompt>? R Enable the interactive entry of the string value\&.label <text> N Name to use in the help, and as primary flag (for an option)\&.list R Declare as list-valued\&.optional G Declare input as optional\&.presence V Declare as boolean option without argument\&.test G Control the matching of words to optional inputs\&.undocumented G Declare as hidden from help\&.validate <cmdprefix> V Declare validation type\&.when-complete <cmdprefix> C Set callback executed when the value becomes known\&.when-set <cmdprefix> C Set callback executed when the string value becomes known\&..CE.PP\fINaming\fR.PPWe have two commands to influence the visible naming of allparameters\&..PPAs background, all parameters are named for properidentification within the framework and other Tcl code, i\&.e\&. thevarious callbacks, including a "private"s action\&. This "system name"has to be unique within the "private" a parameter belongs to\&. Beyondthat however the visible parameters have to be identified within helptexts, and, in case of "options", for detection during "Parsing"\&. Thatis the visible naming, seen by a user of any application whose commandline processing is based on the Cmdr framework\&..TP\fBlabel\fR \fItext\fRThis command declares the visible name, if different from the systemname used as the default\&. Note that in most cases this default is goodenough, obviating the need for this command\&..spThe only use case seen so far is when two semanticallyequivalent input and option parameters clash, requiring differentinternal names due to the requirement for uniqueness, yet also thesame visible name and flag within the help to highlight theirconnection and equivalence\&..TP\fBalias\fR \fIname\fRFor option parameters the "label" command and its default specifiesthe name of the primary flag recognized during parsing\&. If that is notenough for a specific option this command allows the specification ofany number additional flags to be recognized\&..spNote however that the framework automatically recognizes notonly the specified flags, but also all unique prefixes, obviating theneed for this command in many cases\&..PP.PP\fIGeneral control\fR.PPThe general handling of a parameter is influenced by threecommands\&..TP\fBoptional\fRThis command marks the parameter as optional, i\&.e\&. as something theuser may skip on the command line, and the application supplyingsensible defaults\&. --TODO--(sectref:para/vtype)--During parsing the framework will then expend some effort to determinewhether an argument word should be assigned to the parameter, or not\&..spThis setting is only applicable to "inputs", as "options" areoptional by definition, and "state" is hidden\&..TP\fBtest\fRThis command is related to the above, switching from the standardregime for acceptance based on counting and thresholds to a differentone based on validation\&. The details are explained in section--TODO--(sectref:flow/parsing, flow/optional)--\&..TP\fBundocumented\fRLike "officers" and "privates" parameters can be hidden from thegenerated help\&. This is the command for doing so, the same as for thefirst two\&..spThe main use case is the hiding of options giving anapplication developer access to the internals of their application,something a regular user has no need of, and doesn't have to knowabout\&..PP.PP\fIRepresentations\fR.PPAn important concept of parameters is something taken up fromTcl itself\&.The differentation between string and internal representations\&.Where Tcl uses internal representations to speed up its execution herethis separation is that of between the information delivered to theapplication by a user, and the application-specific data structuresbehind them\&..PPAll parameters will have an internal representation\&.This is usually derived from the string representation provided by theuser\&.The details of that process are explained in section--TODO--(sectref:para/vtype)--about validation types\&.However we have cases where the user cannot specify a stringrepresentation ("states"), or is allowed to choose not to (optional"inputs", "options")\&.For these cases three specification commands are made availableenabling us to programmatically choose the internal representation\&..TP\fBdefault\fR \fIvalue\fRThis command provides a constant value for the internalrepresentation\&..TP\fBgenerate\fR \fIcmdprefix\fRThis command provides a callback to compute the internalrepresentation at runtime\&. This is useful if the default is somethingwhich cannot be captured as a fixed value, for example a handle tosome resource, or a dynamically created object\&..spThe command prefix is invoked with a single argument, the\fBcmdr::parameter\fR instance for which to generate the internalrepresentation\&..PP.PPThe commands "default" and "generate" exclude each other,i\&.e\&. only of them can be specified\&.If neither are specified, and we need a default (see the casesabove) a default is chosen per the two rules below:.IP [1]Use the empty string for a "list" parameter\&..IP [2]Use the default value supplied by the chosen validation type(See section --TODO--(sectref:para/vtype)--)\&..PP.TP\fBinteract\fR ?\fIprompt\fR?This command actually does not specify an internal representation, butactivates another method for the user to specify a string value forthe parameter, outside of the command line\&.As such it has priority over either "default" and "generate," and canbe specified with either\&. A parameter marked with it willinteractively ask the user for a value if none was specified on thecommand line\&..spThe default \fIprompt\fR is derived from the system name\&..PP.PPTo recapitulate:.IP [1]A string representation specified on the command line has thehighest priority and goes through the chosen validation type toget the associated internal representation\&..IP [2]If activated via "interact" a small shell is run asking theuser for a value (or more, as per "list", see below)\&. Theresult goes through the chosen validation type to get theassociated internal representation\&..IP [3]After that the internal representation is either the declared"default," or the result of invoking the "generate"callback\&. As internal representations they are \fInot\fR runthrough the chosen validation type\&..PP.TP\fBlist\fRThis command is used to mark parameters whose string and thus internalvalue should be treated as a list\&. By default all parameters are scalar\&..spThis affects the handling of the parameter during parsing, by"interact" above, and the use of the validation type\&. The last two askfor multiple values, and feed the elements of the string valueseparately through validation instead of just the string value in one\&.During parsing treatment of "options" changes from keeping only thelast assigned value to accumulation of all values\&. Similarly alist-"input" takes all remaining words on the command line for itselfinstead of just the current word\&. Because of this list-"inputs" areonly allowed as the last parameter of a "private\&.".PP.PPThe last two specification commands dealing with therepresentations control when the internal representation is created\&..TP\fBdefered\fRThis command marks a parameter as defered, with the internalrepresentation computed on first access to its value\&. This is thedefault for "state" parameters\&..TP\fBimmediate\fRThis command marks a parameter as immediate, with the internalrepresentation computed in the "Completion" phase\&. This is the defaultfor "input" and "option" parameters\&..PP.PP\fIValidation\fR.PPThe answer to the necessity of moving between the string andinternal representations described in the previous section are thevalidation types\&. Given a string representation they either return theassociated internal representation or raise an error, signaling thatthe input was illegal\&. This part of their work, the verification ofthe legality of the input string gave them their name\&..PPThe general concept of validation types was taken from\fBsnit\fR, and modified to suit Cmdr\&. Where snit's typesexpect only a single method to validate the input Cmdrexpects all types to support an ensemble of \fIfour\fR methods, onefor the basic validation and transformation of the input, another forthe release of any internal representation so generated, plus deliveryof a default representation and support for command line completion\&..TP\fBvalidate\fR \fIcmdprefix\fRThis command specifies a validation type for the parameter, in theform of a command prefix\&.The set of methods this callback has to support, their signatures,etc\&. are all explained in \fICmdr - Writing custom validation types\fR\&. This documentcontains the implementation of the standard boolean validation type asan example as well\&..spBecause of the same necessity all parameters must have avalidation type assigned to them, and the system will choose which, ifthe user did not\&. This choice is made per the six rules below andalways returns one of the standard types implemented in package\fBcmdr::validate\fR\&..RS.IP [1]Use "identity" if a "generate" callback is specified\&..IP [2]Use "boolean" if no "default" is specified and the parameter is an option\&..IP [3]Use "identity" if no "default" is specified and the parameter is an input\&..IP [4]Use "boolean" if the specified "default" value is a Tcl boolean\&..IP [5]Use "integer" if the specified "default" value is a Tcl integer\&..IP [6]Use "identity" as fallback of last resort\&..RE.TP\fBpresence\fRThis command is best discussed as part of the wider area of "boolean"options, i\&.e\&. options with validation type "boolean" assigned tothem\&. These have associated special behaviours, both in the handlingof the specification, and during parsing\&..spFirst, normal boolean options\&. They have automatic aliasesdeclared for them, derived from their primary flag\&. An option named"foo" will have an alias of "no-foo", and the reverse\&. During parsingthe "foo" and "no-foo" flags have inverse semantics, and both areallowed to occur without option argument following the flag\&. This isin contrast to all other options which must have such an argument\&. Theparser essentially uses the validation type to decide if the wordafter the flag is a proper boolean value, or not, i\&.e\&. an argument toassign to the parameter, or not\&..spNow "presence" declares a variant of the above, a booleanoption without the automatic aliases, and \fInever\fR taking anargument during parsing\&. Its mere \fIpresence\fR on the command linewill set its parameter\&. Their default value is consequently fixed to\fBfalse\fR as well\&..PP.PP\fISignaling\fROf the four callbacks supported by parameters the first two,"generate" and "validate" have been described already, in the sections--TODO--\\ref{para/reps} about representations and--TODO--\\ref{para/vtype} about validation types, respectively\&..PPThis section explains the commonalities between the callbacksin general, and the last two, for notifications about state changes indetail\&..PPAll callbacks are treated as command prefixes, notscripts\&.There are no placeholder substitutions, only arguments added to eachcommand prefix on invokation\&. This does not harm the generality of thesystem, as complex scripts can be used via procedures or equivalents(i\&.e\&. \fBapply\fR)\&..PPThe two callbacks not yet described are the state-changecallbacks through which the framework can actively drive parts of theapplication while processing the command line, whereas normally theapplication drives access to parameters through their methods\&..TP\fBwhen-complete\fR \fIcmdprefix\fRThis command declares the state-change callback to invoke when theinternal representation of the parameter is generated from the stringrepresentation, or the various ways of getting a default\&..spThe callback is invoked with two arguments, the\fBcmdr::parameter\fR instance of the parameter which changed, andits internal representation, in this order\&..TP\fBwhen-set\fR \fIcmdprefix\fRThis command declares the state-change callback to invoke when thestring representation of the parameter is set during command lineparsing\&..spThe callback is invoked with two arguments, the\fBcmdr::parameter\fR instance of the parameter which changed, andits string representation, in this order\&..PPDue to their nature these callbacks are invoked at runtime duringeither parsing, completion," or execution\&. The details are shown inthe table below\&. The specification commands influencing the timing,i\&.e\&. forcing the use in a specific phase are shown in the intersectionof callback and phase\&..CS | Dispatch | Parsing | Completion | Execution--------------------+----------+---------+-------------+-----------validate (default) | * | | |--------------------+----------+---------+-------------+-----------validate (complete) | | * | immediate | deferedwhen-set | | * | |--------------------+----------+---------+-------------+-----------generate | | | immediate | deferedvalidate (validate) | | test | immediate | deferedvalidate (release) | | test | immediate | defered--------------------+----------+---------+-------------+-----------when-complete | | | immediate | defered--------------------+----------+---------+-------------+-----------.CE
.SH "RELATED DOCUMENTS"
.IP [1]
\fICmdr - Introduction to the project\fR
.IP [2]
\fICmdr - License\fR
.IP [3]
\fICmdr - Log of Changes\fR

..
.de UL
\\$1\l'|0\(ul'\\$2
..
.TH "cmdr_dsl" n 0 doc "Cmdr, a framework for command line parsing and dispatch"
.BS
.SH NAME
cmdr_dsl \- Cmdr - Introduction to the Specification Language
.SH DESCRIPTION
.PP
Welcome to the Cmdr project, written by Andreas Kupries\&.
.PP
For availability please read \fICmdr - How To Get The Sources\fR\&.
.PP
This document is for users of the cmdr framework\&. It introduces the
domain-specific language for the specification of command hierarchies
with commands and their parameters by way of examples and thenprovides links to the detailed reference documents\&..SH "RELATED SPECIFICATION DOCUMENTS".IP [1]\fICmdr - Introduction to the Specification Language\fR.IP [2]\fICmdr - Officer Specification Language\fR.IP [3]\fICmdr - Private Specification Language\fR.IP [4]\fICmdr - Parameter Specification Language\fR.PP
.SH "INTRODUCTORY EXAMPLES"
Instead of immediately diving into the full syntax of the
specification language first a few examples to demonstrate the general
look and feel, plus basic features\&.
.SS "BASIC PRIVATE COMMANDS WITH INPUTS"
.PP
This example specifies a command line providing 3 commands for
the management of command aliases\&.
This is actually a slice of \fBstackato\fR's interface, reduced and
modified to fit here\&.
While it does not have the necessary backend procedures required to
actually run the commands, it is enough to demonstrate basic features,
................................................................................
.CE
.PP
At the bottom of the example, just above we can also see the
very simple Tcl command which invokes the command line processing for
a list of words, here coming from \fB$argv\fR, i\&.e\&. the application's
command line\&.
.SS "SIMPLE COMMAND NESTING"
.PP
The decoupling of command names from their implementations seen
in the previous example makes it easy to re-arrange and re-label the
user visible commands without having to touch any other part of the
code\&.
.PP
This is demonstrated in the example below, moving the 3
................................................................................
\&.\&.\&.
.CE
.SH "LANGUAGE REFERENCE"
With the examples behind us we can now go and specify the entire
specification language\&. If you have skipped here on first reading,
ignoring the examples, please go back and read them first\&.
.PP
The conceptual model underneath the command hierarchy is that
of a tree\&.
.PP
The inner nodes of the tree represent command ensembles, here
called \fIofficer\fRs\&. Each officer knows one or more commands toperform, and delegates actual execution to their respective
specification, which may be another \fIofficer\fR, or a \fIprivate\fR\&.
.PP
The leaf nodes of the tree represent the individual commands,
here called \fIprivate\fRs\&.Each \fIprivate\fR is responsible for a single action and knows howto perform it, and the set of \fIparameter\fRs used to configure that
action at runtime\&.
.PP
The same model is graphically presented in the
Entity-Relationship-Diagram below\&.
.PS
.nf
is-a is-a
/-1:1-> actor <-1:1-\\
................................................................................
\\--/
1:(0-n)
has
.fi
.PE
.PP
The \fIactor\fR in that diagram is the common base class for the
ensembles and commands and not directly relevant to users\&.
.PP
The \fIconfig\fR on the other hand is the second interface
seen by the user, as the sole argument to the action command prefix of
\fBprivate\fR\&. See \fICmdr - Officer Specification Language\fR for the details\&.
This container, an instance of \fBcmdr::config\fR, holds all the
declared parameters of the command the action is invoked for, and
provides easy access to them through its methods at the time ofexecution\&.
.PP
Please continue reading with \fICmdr - Officer Specification Language\fR\&.
.SH "RELATED DOCUMENTS"
.IP [1]
\fICmdr - Introduction to the project\fR
.IP [2]
\fICmdr - License\fR
.IP [3]
\fICmdr - Log of Changes\fR

'\"'\" Generated from file 'cmdr_dsl_officer\&.man' by tcllib/doctools with format 'nroff''\" Copyright (c) 2013 Andreas Kupries'\" Copyright (c) 2013 Documentation, Andreas Kupries'\"'\" The definitions below are for supplemental macros used in Tcl/Tk'\" manual entries.'\"'\" .AP type name in/out ?indent?'\" Start paragraph describing an argument to a library procedure.'\" type is type of argument (int, etc.), in/out is either "in", "out",'\" or "in/out" to describe whether procedure reads or modifies arg,'\" and indent is equivalent to second arg of .IP (shouldn't ever be'\" needed; use .AS below instead)'\"'\" .AS ?type? ?name?'\" Give maximum sizes of arguments for setting tab stops. Type and'\" name are examples of largest possible arguments that will be passed'\" to .AP later. If args are omitted, default tab stops are used.'\"'\" .BS'\" Start box enclosure. From here until next .BE, everything will be'\" enclosed in one large box.'\"'\" .BE'\" End of box enclosure.'\"'\" .CS'\" Begin code excerpt.'\"'\" .CE'\" End code excerpt.'\"'\" .VS ?version? ?br?'\" Begin vertical sidebar, for use in marking newly-changed parts'\" of man pages. The first argument is ignored and used for recording'\" the version when the .VS was added, so that the sidebars can be'\" found and removed when they reach a certain age. If another argument'\" is present, then a line break is forced before starting the sidebar.'\"'\" .VE'\" End of vertical sidebar.'\"'\" .DS'\" Begin an indented unfilled display.'\"'\" .DE'\" End of indented unfilled display.'\"'\" .SO'\" Start of list of standard options for a Tk widget. The'\" options follow on successive lines, in four columns separated'\" by tabs.'\"'\" .SE'\" End of list of standard options for a Tk widget.'\"'\" .OP cmdName dbName dbClass'\" Start of description of a specific option. cmdName gives the'\" option's name as specified in the class command, dbName gives'\" the option's name in the option database, and dbClass gives'\" the option's class in the option database.'\"'\" .UL arg1 arg2'\" Print arg1 underlined, then print arg2 normally.'\"'\" RCS: @(#) $Id: man.macros,v 1.1 2009/01/30 04:56:47 andreas_kupries Exp $'\"'\" # Set up traps and other miscellaneous stuff for Tcl/Tk man pages..if t .wh -1.3i ^B.nr ^l \n(.l.ad b'\" # Start an argument description.de AP.ie !"\\$4"" .TP \\$4.el \{\. ie !"\\$2"" .TP \\n()Cu. el .TP 15.\}.ta \\n()Au \\n()Bu.ie !"\\$3"" \{\\&\\$1 \\fI\\$2\\fP (\\$3).\".b.\}.el \{\.br.ie !"\\$2"" \{\\&\\$1 \\fI\\$2\\fP.\}.el \{\\&\\fI\\$1\\fP.\}.\}..'\" # define tabbing values for .AP.de AS.nr )A 10n.if !"\\$1"" .nr )A \\w'\\$1'u+3n.nr )B \\n()Au+15n.\".if !"\\$2"" .nr )B \\w'\\$2'u+\\n()Au+3n.nr )C \\n()Bu+\\w'(in/out)'u+2n...AS Tcl_Interp Tcl_CreateInterp in/out'\" # BS - start boxed text'\" # ^y = starting y location'\" # ^b = 1.de BS.br.mk ^y.nr ^b 1u.if n .nf.if n .ti 0.if n \l'\\n(.lu\(ul'.if n .fi..'\" # BE - end boxed text (draw box now).de BE.nf.ti 0.mk ^t.ie n \l'\\n(^lu\(ul'.el \{\.\" Draw four-sided box normally, but don't draw top of.\" box if the box started on an earlier page..ie !\\n(^b-1 \{\\h'-1.5n'\L'|\\n(^yu-1v'\l'\\n(^lu+3n\(ul'\L'\\n(^tu+1v-\\n(^yu'\l'|0u-1.5n\(ul'.\}.el \}\\h'-1.5n'\L'|\\n(^yu-1v'\h'\\n(^lu+3n'\L'\\n(^tu+1v-\\n(^yu'\l'|0u-1.5n\(ul'.\}.\}.fi.br.nr ^b 0..'\" # VS - start vertical sidebar'\" # ^Y = starting y location'\" # ^v = 1 (for troff; for nroff this doesn't matter).de VS.if !"\\$2"" .br.mk ^Y.ie n 'mc \s12\(br\s0.el .nr ^v 1u..'\" # VE - end of vertical sidebar.de VE.ie n 'mc.el \{\.ev 2.nf.ti 0.mk ^t\h'|\\n(^lu+3n'\L'|\\n(^Yu-1v\(bv'\v'\\n(^tu+1v-\\n(^Yu'\h'-|\\n(^lu+3n'.sp -1.fi.ev.\}.nr ^v 0..'\" # Special macro to handle page bottom: finish off current'\" # box/sidebar if in box/sidebar mode, then invoked standard'\" # page bottom macro..de ^B.ev 2'ti 0'nf.mk ^t.if \\n(^b \{\.\" Draw three-sided box if this is the box's first page,.\" draw two sides but no top otherwise..ie !\\n(^b-1 \h'-1.5n'\L'|\\n(^yu-1v'\l'\\n(^lu+3n\(ul'\L'\\n(^tu+1v-\\n(^yu'\h'|0u'\c.el \h'-1.5n'\L'|\\n(^yu-1v'\h'\\n(^lu+3n'\L'\\n(^tu+1v-\\n(^yu'\h'|0u'\c.\}.if \\n(^v \{\.nr ^x \\n(^tu+1v-\\n(^Yu\kx\h'-\\nxu'\h'|\\n(^lu+3n'\ky\L'-\\n(^xu'\v'\\n(^xu'\h'|0u'\c.\}.bp'fi.ev.if \\n(^b \{\.mk ^y.nr ^b 2.\}.if \\n(^v \{\.mk ^Y.\}..'\" # DS - begin display.de DS.RS.nf.sp..'\" # DE - end display.de DE.fi.RE.sp..'\" # SO - start of list of standard options.de SO.SH "STANDARD OPTIONS".LP.nf.ta 4c 8c 12c.ft B..'\" # SE - end of list of standard options.de SE.fi.ft R.LPSee the \\fBoptions\\fR manual entry for details on the standard options...'\" # OP - start of full description for a single option.de OP.LP.nf.ta 4cCommand-Line Name: \\fB\\$1\\fRDatabase Name: \\fB\\$2\\fRDatabase Class: \\fB\\$3\\fR.fi.IP..'\" # CS - begin code excerpt.de CS.RS.nf.ta .25i .5i .75i 1i..'\" # CE - end code excerpt.de CE.fi.RE...de UL\\$1\l'|0\(ul'\\$2...TH "cmdr_dsl_officer" n 0 doc "Cmdr, a framework for command line parsing and dispatch".BS.SH NAMEcmdr_dsl_officer \- Cmdr - Officer Specification Language.SH SYNOPSIS\fBalias\fR \fIname\fR \fB=\fR \fIname'\fR\&.\&.\&..sp\fBalias\fR \fIname\fR.sp\fBcommon\fR \fIname\fR \fItext\fR.sp\fBdefault\fR.sp\fBdescription\fR \fItext\fR.sp\fBehandler\fR \fIcmdprefix\fR.sp\fBofficer\fR \fIname\fR \fIscript\fR.sp\fBprivate\fR \fIname\fR \fIscript\fR \fIcmdprefix\fR.sp\fBundocumented\fR.sp.BE.SH DESCRIPTION.PPWelcome to the Cmdr project, written by Andreas Kupries\&..PPFor availability please read \fICmdr - How To Get The Sources\fR\&..PPThis document is for users of the cmdr framework\&. It introduces thedomain-specific language for the specification of \fIofficer\fRs indetail\&..SH "RELATED SPECIFICATION DOCUMENTS".IP [1]\fICmdr - Introduction to the Specification Language\fR.IP [2]\fICmdr - Officer Specification Language\fR.IP [3]\fICmdr - Private Specification Language\fR.IP [4]\fICmdr - Parameter Specification Language\fR.PP.SH "LANGUAGE REFERENCE".TP\fBalias\fR \fIname\fR \fB=\fR \fIname'\fR\&.\&.\&..TP\fBalias\fR \fIname\fRThis is a structuring command, for the command hierarchy\&. Its mainuses are the creation of alternate command names, and of shortcutsthrough the command hierarchy\&..spFor example, \fBstackato\fR's command specification foralias management is written using deep nesting and uses aliases toprovide the look of a flat namespace to application users\&..spIn the first form the \fIname\fR is given the explicit path tothe actor the name is an alias for\&.In the second form the alias implicitly refers to the immediatelypreceding \fIofficer\fR or \fIprivate\fR\&.Note that "immediately" is interpreted at the current level\&. Thesystem is \fInot\fR looking into a nested specification for its lastcommand\&..RS.TPstring \fIname\fRThe name of the alias\&..TPstring \fIname'\&.\&.\&.\fRThe path to the actor, as list of names\&..RE.TP\fBcommon\fR \fIname\fR \fItext\fRThis is another structuring command, for structuring the specificationitself instead of the command tree it declares\&..spIt creates named values, usually code blocks, which can beshared between specifications\&. Note that while each block is visiblein the current \fIofficer\fR and its subordinates, parents andsiblings have no access\&..spAn example of such a block would be.CScommon *all* { option debug { Activate client internal tracing\&. } { undocumented list when-complete [lambda {p tags} { foreach t $tags { debug on $t } }] }}.CE.IPThis example defines an option to access the subsystem for debugnarative (See package \fBTcllib\fR)\&.The example is actually special, as the block named \fB*all*\fR isreserved by the framework\&.This block, if defined, is automatically included at the front of all\fIprivate\fR specifications, i\&.e\&. shared across all the privatesspecified underneath this \fIofficer\fR\&. A very important trait forthe \fIoption\fR in the example, as it makes the debug setupavailable to all privates without having to explicitly include theblock, and possibly forgetting such\&..spGenerally speaking, the framework reserves all blocks whosename begins with a star, i\&.e \fB*\fR, for its own use\&..RS.TPstring \fIname\fRThe name of the common block\&..TPstring \fItext\fRThe text of the block\&..RE.TP\fBdefault\fRThis command sets up a special kind of alias\&.The last \fIprivate\fR or \fIofficer\fR is set as the defaultcommand to use at runtime\&.This means that if during "Dispatch" phase the currently processedword does not match any of the commands known to this \fIofficer\fRthis default is used\&. If no default is specified an error will bethrown instead\&..TP\fBdescription\fR \fItext\fRThis command declares the help text of the \fIofficer\fR\&..TP\fBehandler\fR \fIcmdprefix\fRThis is an advanced command which should normally only be specified atthe top of the whole hierarchy (from which its value willautomatically propagate to all subordinates)\&..spAt runtime the framework will call the specified command prefixwith a single argument, a script whose execution is equivalent to thephases "Parsing", "Completion", and "Execution" of the framework, asdescribed in --TODO--(sectref:flow/phases)--\&. The handler \fImust\fRcall this script, and can perform any application-specific actionsbefore and after\&..spThis handler's main uses are two-fold:.RS.IP [1]Capture and hande application-specific errors which should notabort the application, nor shown as Tcl stacktrace\&..IP [2]Cleanup of application-specific transient state the\fIparameter\fR callbacks (See \fICmdr - Parameter Specification Language\fR)and/or actions may have set during their execution\&.This is especially important if the interactive command line shells ofthe framework are enabled\&. Without such a handler and its bespokecleanup code transient state \fIwill\fR leak between multiplecommands run from such a shell, something which is definitely notwanted\&..RE.TP\fBofficer\fR \fIname\fR \fIscript\fRThis command creates a named subordinate \fIofficer\fR with itsspecification \fIscript\fR of officer commands as described here\&..TP\fBprivate\fR \fIname\fR \fIscript\fR \fIcmdprefix\fRThis command creates a named subordinate \fIprivate\fR with itsspecification \fIscript\fR of private commands(See \fICmdr - Private Specification Language\fR), and a command prefix to invokewhen it is chosen\&..spThis command prefix is called with a single argument, the\fBcmdr::config\fR instance holding the \fIparameter\fRs of theprivate\&.--TODO--(ref:backend-example-code)--.TP\fBundocumented\fRThis command excludes the \fIofficer\fR (and its subordinates) fromthe generated help\&.Note that subordinates reachable through aliases may be included,under the alias name, if they are not explicitly excluded themselves\&..PP.PPPlease continue reading with \fICmdr - Private Specification Language\fR\&..SH "RELATED DOCUMENTS".IP [1]\fICmdr - Introduction to the project\fR.IP [2]\fICmdr - License\fR.IP [3]\fICmdr - Log of Changes\fR.IP [4]\fICmdr - How To Get The Sources\fR.IP [5]\fICmdr - The Installer's Guide\fR.IP [6]\fICmdr - The Developer's Guide\fR.PP.SH "BUGS, IDEAS, FEEDBACK"Both the package(s) and this documentation will undoubtedly containbugs and other problems\&.Please report such at\fICmdr Tickets\fR [https:/core\&.tcl\&.tk/akupries/cmdr]\&..PPPlease also report any ideas you may have for enhancements ofeither package(s) and/or documentation\&..SH KEYWORDSarguments, command hierarchy, command line completion, command line handling, command tree, editing command line, help for command line, hierarchy of commands, interactive command shell, optional arguments, options, parameters, processing command line, tree of commands.SH COPYRIGHT.nfCopyright (c) 2013 Andreas KupriesCopyright (c) 2013 Documentation, Andreas Kupries.fi

'\"'\" Generated from file 'cmdr_dsl_parameter\&.man' by tcllib/doctools with format 'nroff''\" Copyright (c) 2013 Andreas Kupries'\" Copyright (c) 2013 Documentation, Andreas Kupries'\"'\" The definitions below are for supplemental macros used in Tcl/Tk'\" manual entries.'\"'\" .AP type name in/out ?indent?'\" Start paragraph describing an argument to a library procedure.'\" type is type of argument (int, etc.), in/out is either "in", "out",'\" or "in/out" to describe whether procedure reads or modifies arg,'\" and indent is equivalent to second arg of .IP (shouldn't ever be'\" needed; use .AS below instead)'\"'\" .AS ?type? ?name?'\" Give maximum sizes of arguments for setting tab stops. Type and'\" name are examples of largest possible arguments that will be passed'\" to .AP later. If args are omitted, default tab stops are used.'\"'\" .BS'\" Start box enclosure. From here until next .BE, everything will be'\" enclosed in one large box.'\"'\" .BE'\" End of box enclosure.'\"'\" .CS'\" Begin code excerpt.'\"'\" .CE'\" End code excerpt.'\"'\" .VS ?version? ?br?'\" Begin vertical sidebar, for use in marking newly-changed parts'\" of man pages. The first argument is ignored and used for recording'\" the version when the .VS was added, so that the sidebars can be'\" found and removed when they reach a certain age. If another argument'\" is present, then a line break is forced before starting the sidebar.'\"'\" .VE'\" End of vertical sidebar.'\"'\" .DS'\" Begin an indented unfilled display.'\"'\" .DE'\" End of indented unfilled display.'\"'\" .SO'\" Start of list of standard options for a Tk widget. The'\" options follow on successive lines, in four columns separated'\" by tabs.'\"'\" .SE'\" End of list of standard options for a Tk widget.'\"'\" .OP cmdName dbName dbClass'\" Start of description of a specific option. cmdName gives the'\" option's name as specified in the class command, dbName gives'\" the option's name in the option database, and dbClass gives'\" the option's class in the option database.'\"'\" .UL arg1 arg2'\" Print arg1 underlined, then print arg2 normally.'\"'\" RCS: @(#) $Id: man.macros,v 1.1 2009/01/30 04:56:47 andreas_kupries Exp $'\"'\" # Set up traps and other miscellaneous stuff for Tcl/Tk man pages..if t .wh -1.3i ^B.nr ^l \n(.l.ad b'\" # Start an argument description.de AP.ie !"\\$4"" .TP \\$4.el \{\. ie !"\\$2"" .TP \\n()Cu. el .TP 15.\}.ta \\n()Au \\n()Bu.ie !"\\$3"" \{\\&\\$1 \\fI\\$2\\fP (\\$3).\".b.\}.el \{\.br.ie !"\\$2"" \{\\&\\$1 \\fI\\$2\\fP.\}.el \{\\&\\fI\\$1\\fP.\}.\}..'\" # define tabbing values for .AP.de AS.nr )A 10n.if !"\\$1"" .nr )A \\w'\\$1'u+3n.nr )B \\n()Au+15n.\".if !"\\$2"" .nr )B \\w'\\$2'u+\\n()Au+3n.nr )C \\n()Bu+\\w'(in/out)'u+2n...AS Tcl_Interp Tcl_CreateInterp in/out'\" # BS - start boxed text'\" # ^y = starting y location'\" # ^b = 1.de BS.br.mk ^y.nr ^b 1u.if n .nf.if n .ti 0.if n \l'\\n(.lu\(ul'.if n .fi..'\" # BE - end boxed text (draw box now).de BE.nf.ti 0.mk ^t.ie n \l'\\n(^lu\(ul'.el \{\.\" Draw four-sided box normally, but don't draw top of.\" box if the box started on an earlier page..ie !\\n(^b-1 \{\\h'-1.5n'\L'|\\n(^yu-1v'\l'\\n(^lu+3n\(ul'\L'\\n(^tu+1v-\\n(^yu'\l'|0u-1.5n\(ul'.\}.el \}\\h'-1.5n'\L'|\\n(^yu-1v'\h'\\n(^lu+3n'\L'\\n(^tu+1v-\\n(^yu'\l'|0u-1.5n\(ul'.\}.\}.fi.br.nr ^b 0..'\" # VS - start vertical sidebar'\" # ^Y = starting y location'\" # ^v = 1 (for troff; for nroff this doesn't matter).de VS.if !"\\$2"" .br.mk ^Y.ie n 'mc \s12\(br\s0.el .nr ^v 1u..'\" # VE - end of vertical sidebar.de VE.ie n 'mc.el \{\.ev 2.nf.ti 0.mk ^t\h'|\\n(^lu+3n'\L'|\\n(^Yu-1v\(bv'\v'\\n(^tu+1v-\\n(^Yu'\h'-|\\n(^lu+3n'.sp -1.fi.ev.\}.nr ^v 0..'\" # Special macro to handle page bottom: finish off current'\" # box/sidebar if in box/sidebar mode, then invoked standard'\" # page bottom macro..de ^B.ev 2'ti 0'nf.mk ^t.if \\n(^b \{\.\" Draw three-sided box if this is the box's first page,.\" draw two sides but no top otherwise..ie !\\n(^b-1 \h'-1.5n'\L'|\\n(^yu-1v'\l'\\n(^lu+3n\(ul'\L'\\n(^tu+1v-\\n(^yu'\h'|0u'\c.el \h'-1.5n'\L'|\\n(^yu-1v'\h'\\n(^lu+3n'\L'\\n(^tu+1v-\\n(^yu'\h'|0u'\c.\}.if \\n(^v \{\.nr ^x \\n(^tu+1v-\\n(^Yu\kx\h'-\\nxu'\h'|\\n(^lu+3n'\ky\L'-\\n(^xu'\v'\\n(^xu'\h'|0u'\c.\}.bp'fi.ev.if \\n(^b \{\.mk ^y.nr ^b 2.\}.if \\n(^v \{\.mk ^Y.\}..'\" # DS - begin display.de DS.RS.nf.sp..'\" # DE - end display.de DE.fi.RE.sp..'\" # SO - start of list of standard options.de SO.SH "STANDARD OPTIONS".LP.nf.ta 4c 8c 12c.ft B..'\" # SE - end of list of standard options.de SE.fi.ft R.LPSee the \\fBoptions\\fR manual entry for details on the standard options...'\" # OP - start of full description for a single option.de OP.LP.nf.ta 4cCommand-Line Name: \\fB\\$1\\fRDatabase Name: \\fB\\$2\\fRDatabase Class: \\fB\\$3\\fR.fi.IP..'\" # CS - begin code excerpt.de CS.RS.nf.ta .25i .5i .75i 1i..'\" # CE - end code excerpt.de CE.fi.RE...de UL\\$1\l'|0\(ul'\\$2...TH "cmdr_dsl_parameter" n 0 doc "Cmdr, a framework for command line parsing and dispatch".BS.SH NAMEcmdr_dsl_parameter \- Cmdr - Parameter Specification Language.SH SYNOPSIS\fBlabel\fR \fItext\fR.sp\fBalias\fR \fIname\fR.sp\fBoptional\fR.sp\fBtest\fR.sp\fBundocumented\fR.sp\fBdefault\fR \fIvalue\fR.sp\fBgenerate\fR \fIcmdprefix\fR.sp\fBinteract\fR ?\fIprompt\fR?.sp\fBlist\fR.sp\fBdefered\fR.sp\fBimmediate\fR.sp\fBvalidate\fR \fIcmdprefix\fR.sp\fBpresence\fR.sp\fBwhen-complete\fR \fIcmdprefix\fR.sp\fBwhen-set\fR \fIcmdprefix\fR.sp.BE.SH DESCRIPTION.PPWelcome to the Cmdr project, written by Andreas Kupries\&..PPFor availability please read \fICmdr - How To Get The Sources\fR\&..PPThis document is for users of the cmdr framework\&. It introduces thedomain-specific language for the specification of parameters indetail\&..SH "RELATED SPECIFICATION DOCUMENTS".IP [1]\fICmdr - Introduction to the Specification Language\fR.IP [2]\fICmdr - Officer Specification Language\fR.IP [3]\fICmdr - Private Specification Language\fR.IP [4]\fICmdr - Parameter Specification Language\fR.PP.SH "LANGUAGE REFERENCE".PPThe \fIparameter\fRs of \fIprivate\fRs are the heart of thesystem, providing the space needed to transfer command arguments totheir implementations, and having the most attributes controllingtheir behaviour\&..PPThis complexity is strongly mitigated by the use of sensibledefaults for each of the three possible kinds of parameter, i\&.e\&.positional \fIinput\fRs, named \fIoption\fRs", and \fIstate\fRhidden from the command line\&..PPEach kind has its own construction command in the language for\fIprivate\fRs (See \fICmdr - Private Specification Language\fR) which specifiesthe common information which cannot have defaults, i\&.e\&..IP [1]the name identifying it to the system,.IP [2]the help text describing it in informal speech, and, of course,.IP [3]the parameter specification itself, using the commands of this section\&..PP.PP.SS NAMING.PPWe have two commands to influence the visible naming of all\fIparameter\fRs\&..PPAs background, all \fIparameter\fRs are named, to properlyidentify them within the framework and other Tcl code, i\&.e\&. in thevarious callbacks and the \fIprivate\fR's action\&.This \fIsystem name\fR has to be unique within the \fIprivate\fR a\fIparameter\fR belongs to\&.Beyond that however the visible (i\&.e\&. non-term state])\fIparameter\fRs have to be identified by users within help texts,and, in the case of \fIoption\fRs, for detection during the\fIParsing\fR phase\&.That is the visible naming, seen by a user of any application whosecommand line processing is based on the Cmdr framework\&..TP\fBlabel\fR \fItext\fRThis command declares the \fIparameter\fR's visible name, ifdifferent from the \fIsystem name\fR used as the default\&. Note thatin most cases this default is good enough, obviating the need for thiscommand\&..spThe only use case seen so far is when two semanticallyequivalent \fIinput\fR and \fIoption\fR \fIparameter\fRs clash,forcing the use of different system names due to the requirement fortheir uniqueness, yet also use the same visible name and flag withinthe help to highlight their connection and equivalence\&..TP\fBalias\fR \fIname\fRFor \fIoption\fRs the \fBlabel\fR command and its default specifiesthe name of the \fIprimary flag\fR recognized during the\fIParsing\fR phase\&.If that is not enough for a specific \fIoption\fR this command allowsthe specification of any number additional flags to be recognized\&..spNote however that the framework automatically recognizes notonly the specified flag(s), but also all their unique prefixes,obviating the need for this command in many cases\&..PP.PP.SS "GENERAL CONTROL".PPThe general handling of a \fIparameter\fR is influenced bythree commands:.TP\fBoptional\fRThis command marks the parameter as \fIoptional\fR, i\&.e\&. as somethingthe user may skip on the command line, with the application supplyingsensible defaults (See section \fBRepresentations\fR)\&.This causes the framework to expend some effort in the \fIParsing\fRphase to determine whether an argument word should be assigned to theparameter, or not\&..spThis setting is only applicable to \fIinput\fRs, as\fIoption\fRs are optional by definition, and \fIstate\fR is hidden\&..TP\fBtest\fRThis command is related to the above, switching the runtime from thestandard regime for acceptance (based on counting and thresholds) to adifferent regime based on validation\&.The details are explained in --TODO--(sectref:flow/parsing,flow/optional)--\&..TP\fBundocumented\fRThis command excludes the \fIparameter\fR from the generated help\&..spIts main use case is the hiding of \fIoption\fRs giving anapplication developer access to the internals of their application,something a regular user has no need of, and doesn't have to knowabout\&..PP.PP.SS REPRESENTATIONS.PPAn important concept of \fIparameter\fRs is something taken upfrom Tcl itself\&.The differentation between \fIstring\fR and \fIinternal representations\fR\&.Where Tcl uses \fIinternal representations\fR to speed up itsexecution here this separation is that of between the informationdelivered to the application by a user, and the application-specificdata structures behind them\&..PPAll \fIparameter\fRs will have an \fIinternal representation\fR\&.This is usually derived from the \fIstring representation\fRprovided by the user\&.The details of that process are explained in section \fBValidation\fR\&.However we have cases where the user cannot specify a stringrepresentation (\fIstate\fRs), or is allowed to choose not to(optional \fIinput\fRs, \fIoption\fRs)\&.For these cases three specification commands are made availableenabling us to programmatically choose the internal representation\&..TP\fBdefault\fR \fIvalue\fRThis command specifies a constant default value for the internalrepresentation\&..TP\fBgenerate\fR \fIcmdprefix\fRThis command specifies a callback to compute the default internalrepresentation at runtime\&. This is useful if the default is somethingwhich cannot be captured as a fixed value\&. An example would be ahandle to some resource, or a dynamically created object\&..spThe command prefix is invoked with a single argument, the\fBcmdr::parameter\fR instance for which to generate the internalrepresentation\&..PP.PPThe commands \fBdefault\fR and \fBgenerate\fR exclude eachother, i\&.e\&. only of them can be specified, but not both\&.If neither are specified, and we need a default (see the cases above)then a default is chosen by the framework itself, as per the two rulesbelow:.IP [1]Use the empty string for a \fBlist\fR parameter\&..IP [2]Use the default value supplied by the chosen\fIvalidation type\fR (See section \fBValidation\fR)\&..PP.TP\fBinteract\fR ?\fIprompt\fR?This command actually does not specify an\fIinternal representation\fR, but activates another method for theuser to specify the \fIstring representation\fR of the\fIparameter\fR, outside of the command line\&.As such it has priority over either \fBdefault\fR and \fBgenerate\fR,and can be specified with either\&. A \fIparameter\fR marked with itwill interactively ask the user for a value if none was specified onthe command line\&..spThe default for the \fIprompt\fR is derived from the\fIparameter\fR's \fIsystem name\fR\&..PP.PPTo recapitulate:.IP [1]A \fIstring representation\fR specified on the command linehas the highest priority and goes through the chosen\fIvalidation type\fR to get the associated\fIinternal representation\fR\&..IP [2]If activated via \fBinteract\fR a small shell is run asking theuser for a value (or more, as per \fBlist\fR, see below)\&. The resultgoes through the chosen \fIvalidation type\fR to get the associated\fIinternal representation\fR\&..IP [3]After that the \fIinternal representation\fR is either thedeclared \fBdefault\fR value, or the result of invoking the\fBgenerate\fR callback\&.As \fIinternal representation\fRs the resulting values are\fInot\fR run through the chosen \fIvalidation type\fR\&..PP.TP\fBlist\fRThis command marks the \fIparameter\fR as a list\&. In other words, its\fIstring\fR and \fIinternal representation\fR is actually a listof such, instead of a single value\&.By default all parameters are scalar\&..spThis affects the handling of the parameter by the\fIParsing\fR phase, by \fBinteract\fR above, and the use of the\fIvalidation type\fR\&.The last two ask for multiple values, and feed the elements of the\fIstring representation\fR separately through validation insteadof just the string value in one\&.In the \fIParsing\fR phase treatment of \fIoption\fRs changes fromkeeping only the last assigned value to the accumulation of allvalues\&.Similarly a list-\fIinput\fR takes all the remaining words on thecommand line for itself instead of just the current word\&. Because ofthis list-\fIinputs\fR are only allowed as the last \fIparameter\fRof a \fIprivate\fR\&..PP.PPThe last two specification commands dealing with therepresentations control \fIwhen\fR the\fIinternal representation\fR is created\&..TP\fBdefered\fRThis command marks a \fIparameter\fR as \fIdefered\fR, causing its\fIinternal representation\fR to be computed on first access to itsvalue\&. This is the default for \fIstate\fR parameters\&..TP\fBimmediate\fRThis command marks a \fIparameter\fR as \fIimmediate\fR, causing its\fIinternal representation\fR to be computed in the\fICompletion\fR phase\&.This is the default for \fIinput\fR and \fIoption\fR parameters\&..PP.PP.SS VALIDATION.PPThe answer to the necessity of moving between the \fIstring\fRand \fIinternal representations\fR described in the previoussection are the \fIvalidation types\fR\&.Given a \fIstring representation\fR they either return theassociated \fIinternal representation\fR or raise an error,signaling that the string was illegal\&. This part of their work, theverification of the legality of the input string gave them their name\&..PPThe general concept of \fIvalidation types\fR was taken from\fBsnit\fR, and modified to suit Cmdr\&.Where snit's types expect only a single method to validate the inputCmdr expects all types to support an ensemble of \fIfour\fRmethods, one for the basic validation and transformation of the input,another for the release of any internal representation so generated,plus delivery of a default representation and support for command linecompletion\&..TP\fBvalidate\fR \fIcmdprefix\fRThis command specifies a \fIvalidation type\fR for the\fIparameter\fR, in the form of a command prefix (or the name of oneof the builtin types, see package \fBcmdr::validate\fR)\&.The set of methods this callback has to support, their signatures,etc\&. are all explained in \fICmdr - Writing custom validation types\fR\&. This documentcontains the implementation of the standard boolean validation type asan example as well\&..spBecause of the same necessity all \fIparameter\fRs must have a\fIvalidation type\fR assigned to them, and the system will choosewhich, if the user did not\&. This choice is made as per the six rulesbelow and always returns one of the standard types implemented bypackage \fBcmdr::validate\fR\&..RS.IP [1]Use \fBidentity\fR if a \fBgenerate\fR callback is specified\&..IP [2]Use \fBboolean\fR if no \fBdefault\fR is specified and the parameter is an \fIoption\fR\&..IP [3]Use \fBidentity\fR if no \fBdefault\fR is specified and the parameter is an \fIinput\fR\&..IP [4]Use \fBboolean\fR if the specified \fBdefault\fR value is a Tcl boolean\&..IP [5]Use \fBinteger\fR if the specified \fBdefault\fR value is a Tcl integer\&..IP [6]Use \fBidentity\fR as fallback of last resort\&..RE.TP\fBpresence\fRThis command is best discussed as part of the wider area of\fIboolean\fR \fIoption\fRs, i\&.e\&. \fIoption\fRs with the standard\fIvalidation type\fR \fBboolean\fR assigned to them\&. These haveassociated special behaviours, both in the handling of thespecification, and in the \fIParsing\fR phase\&..spFirst, normal boolean options\&.They have automatic aliases declared for them, derived from theirprimary flag\&.An option named "foo" will have an alias of "no-foo", and thereverse\&.In the \fIParsing\fR phase the "foo" and "no-foo" flags have inversesemantics, and both are allowed to occur without option argumentfollowing the flag\&.This is in contrast to all other \fIoption\fRs which must have suchan argument\&. The parser essentially uses the \fIvalidation type\fRto decide if the word after the flag is a proper boolean value, ornot, i\&.e\&. an argument to assign to the \fIparameter\fR, or not\&..spNow \fBpresence\fR declares a variant of the above, a booleanoption \fIwithout\fR the automatic aliases, and \fInever\fR takingan argument during parsing\&.Its mere \fIpresence\fR on the command line will set its\fIparameter\fR\&.Their \fBdefault\fR value is consequently fixed to \fBfalse\fR aswell\&..PP.PP.SS SIGNALINGOf the four callbacks supported by parameters the first two,\fBgenerate\fR and \fBvalidate\fR have been described already, in thesections \fBRepresentations\fR and \fBValidation\fR,respectively\&..PPThis section explains the commonalities between the callbacksin general, and the last two, for notifications about state changes indetail\&..PPAll callbacks are treated as command prefixes, not scripts\&.There are no placeholder substitutions, only arguments added to eachcommand prefix on invokation\&. This does not harm the generality of thesystem, as complex scripts can be used via procedures or equivalents(i\&.e\&. \fBapply\fR)\&..PPThe two callbacks not yet described are the state-changecallbacks through which the framework can actively drive parts of theapplication while processing the command line, whereas normally theapplication drives access to parameters through their methods\&..TP\fBwhen-complete\fR \fIcmdprefix\fRThis command declares the state-change callback to invoke when the\fIinternal representation\fR of the \fIparameter\fR is generatedfrom the \fIstring representation\fR, or the various ways ofgetting a default\&..spThe callback is invoked with two arguments, the\fBcmdr::parameter\fR instance of the changed \fIparameter\fR,and its \fIinternal representation\fR, in this order\&..TP\fBwhen-set\fR \fIcmdprefix\fRThis command declares the state-change callback to invoke when the\fIstring representation\fR of the \fIparameter\fR is set duringcommand line parsing\&..spThe callback is invoked with two arguments, the\fBcmdr::parameter\fR instance of the changed \fIparameter\fR,and its \fIstring representation\fR, in this order\&..PPDue to their nature these callbacks are invoked at runtime duringeither the \fIParsing\fR, \fICompletion\fR, or \fIExecution\fRphases\&.The details are shown in the table below\&. The specification commandsinfluencing the timing, i\&.e\&. forcing the use in a specific phase areshown in the intersection of callback and phase\&..CS | Dispatch | Parsing | Completion | Execution--------------------+----------+---------+-------------+-----------validate (default) | * | | |--------------------+----------+---------+-------------+-----------validate (complete) | | * | immediate | deferedwhen-set | | * | |--------------------+----------+---------+-------------+-----------generate | | | immediate | deferedvalidate (validate) | | test | immediate | deferedvalidate (release) | | test | immediate | defered--------------------+----------+---------+-------------+-----------when-complete | | | immediate | defered--------------------+----------+---------+-------------+-----------.CE.SH "RELATED DOCUMENTS".IP [1]\fICmdr - Introduction to the project\fR.IP [2]\fICmdr - License\fR.IP [3]\fICmdr - Log of Changes\fR.IP [4]\fICmdr - How To Get The Sources\fR.IP [5]\fICmdr - The Installer's Guide\fR.IP [6]\fICmdr - The Developer's Guide\fR.PP.SH "BUGS, IDEAS, FEEDBACK"Both the package(s) and this documentation will undoubtedly containbugs and other problems\&.Please report such at\fICmdr Tickets\fR [https:/core\&.tcl\&.tk/akupries/cmdr]\&..PPPlease also report any ideas you may have for enhancements ofeither package(s) and/or documentation\&..SH KEYWORDSarguments, command hierarchy, command line completion, command line handling, command tree, editing command line, help for command line, hierarchy of commands, interactive command shell, optional arguments, options, parameters, processing command line, tree of commands.SH COPYRIGHT.nfCopyright (c) 2013 Andreas KupriesCopyright (c) 2013 Documentation, Andreas Kupries.fi

.de CE
.fi
.RE
..
.de UL
\\$1\l'|0\(ul'\\$2
..
.TH "cmdr_officer" n 0 doc "Cmdr, a framework for command line parsing and dispatch"
.BS
.SH NAME
cmdr_officer \- Cmdr - Aggregation of multiple commands for dispatch\&.
.SH SYNOPSIS
package require \fBcmdr::util \fR
.sp
\fB::cmdr::officer\fR \fBnew\fR \fIsuper\fR \fIname\fR \fIactions\fR
.sp
\fB::cmdr::officer\fR \fBcreate\fR \fIobj\fR \fIsuper\fR \fIname\fR \fIactions\fR
.sp
\fB<officer>\fR \fBchildren\fR
.sp
................................................................................
The instance command of the actor (officer actually) which contains the new officer\&.
.TP
string \fIname\fR
The user-visible name of the command\&.
.TP
script \fIactions\fR
The specification of the officer's subordinates\&.
Please read \fICmdr - Specification Language\fR (section "Officers") for the details\&.
.RE
.PP
.SH "INSTANCE API"
The instance API is not public\&. It is used internally by the framework
during the parsing of a command hierarchy specification to configure
the officer instances, and when processing a command line at runtime
to manage navigation of the hierarchy, word-completion, etc\&.
................................................................................
script \fIpath\fR
The list of names specifying the route from this officer to the new
private\&. The last element is the name of the private command, while
the preceding names specify the intermediate officers\&.
.TP
script \fIarguments\fR
The specification of the private's parameters\&.
Please read \fICmdr - Specification Language\fR (section "Parameters") for the details\&.
.TP
cmd-prefix \fIaction\fR
The command prefix to invoke when this private is selected for
execution\&. It takes a single argument, the instance command of the
hidden \fBcmdr::config\fR container holding the private's
parameters\&. The result of the action, if there is any, is ignored by
the framework\&.
................................................................................
the set of subordinates known to this officer\&. This is the same type
of script as used during construction, except here we dynamically
extend the officer\&.
.RS
.TP
script \fIactions\fR
The specification of the officer's additional subordinates\&.
Please read \fICmdr - Specification Language\fR (section "Officers") for the details\&.
.RE
.TP
\fB<officer>\fR \fBlookup\fR \fIname\fR
This method returns the instance command of the sub-ordinate with the
given \fIname\fR\&. An error is thrown if such a sub-ordinate does not
exist\&. See also method \fBhas\fR\&.
.RS

.de CE
.fi
.RE
..
.de UL
\\$1\l'|0\(ul'\\$2
..
.TH "cmdr::officer" n 0 doc "Cmdr, a framework for command line parsing and dispatch"
.BS
.SH NAME
cmdr::officer \- Cmdr - Aggregation of multiple commands for dispatch\&.
.SH SYNOPSIS
package require \fBcmdr::officer \fR
.sp
\fB::cmdr::officer\fR \fBnew\fR \fIsuper\fR \fIname\fR \fIactions\fR
.sp
\fB::cmdr::officer\fR \fBcreate\fR \fIobj\fR \fIsuper\fR \fIname\fR \fIactions\fR
.sp
\fB<officer>\fR \fBchildren\fR
.sp
................................................................................
The instance command of the actor (officer actually) which contains the new officer\&.
.TP
string \fIname\fR
The user-visible name of the command\&.
.TP
script \fIactions\fR
The specification of the officer's subordinates\&.
Please read \fICmdr - Officer Specification Language\fR for the details\&.
.RE
.PP
.SH "INSTANCE API"
The instance API is not public\&. It is used internally by the framework
during the parsing of a command hierarchy specification to configure
the officer instances, and when processing a command line at runtime
to manage navigation of the hierarchy, word-completion, etc\&.
................................................................................
script \fIpath\fR
The list of names specifying the route from this officer to the new
private\&. The last element is the name of the private command, while
the preceding names specify the intermediate officers\&.
.TP
script \fIarguments\fR
The specification of the private's parameters\&.
Please read \fICmdr - Parameter Specification Language\fR for the details\&.
.TP
cmd-prefix \fIaction\fR
The command prefix to invoke when this private is selected for
execution\&. It takes a single argument, the instance command of the
hidden \fBcmdr::config\fR container holding the private's
parameters\&. The result of the action, if there is any, is ignored by
the framework\&.
................................................................................
the set of subordinates known to this officer\&. This is the same type
of script as used during construction, except here we dynamically
extend the officer\&.
.RS
.TP
script \fIactions\fR
The specification of the officer's additional subordinates\&.
Please read \fICmdr - Officer Specification Language\fR for the details\&.
.RE
.TP
\fB<officer>\fR \fBlookup\fR \fIname\fR
This method returns the instance command of the sub-ordinate with the
given \fIname\fR\&. An error is thrown if such a sub-ordinate does not
exist\&. See also method \fBhas\fR\&.
.RS

.TH "cmdr_vtypes" n 0 doc "Cmdr, a framework for command line parsing and dispatch"
.BS
.SH NAME
cmdr_vtypes \- Cmdr - Writing custom validation types
.SH SYNOPSIS
package require \fBcmdr::validate \fR
.sp
\fBcmd\fR \fBcomplete\fR \fIp\fR \fIx\fR
.sp
\fBcmd\fR \fBdefault\fR \fIp\fR
.sp
\fBcmd\fR \fBrelease\fR \fIp\fR \fIx\fR
.sp
\fBcmd\fR \fBvalidate\fR \fIp\fR \fIx\fR
.sp
.BE
.SH DESCRIPTION
.PP
Welcome to the Cmdr project, written by Andreas Kupries\&.
.PP
For availability please read \fICmdr - How To Get The Sources\fR\&.
.PP
This document describes the API expected of validation types to make
them usable within the Cmdr framework, and how to write a
custom validation type\&.
.PP
Readers interested in the standard validation types of the
framework should read \fICmdr - Standard validation types for parameters\fR\&.
.SH BACKGROUND
Validation types are Cmdr's answer to the necessity of moving
between the string and internal representations of
\fBcmdr::parameter\fR instances\&.
................................................................................
Because of the same necessity all parameters must have a
validation type assigned to them, and the framework will choose which,
if the user did not\&. This choice is made per the six rules below and
always returns one of the builtins described in \fICmdr - Standard validation types for parameters\fR\&.
.IP [1]
Use \fBidentity\fR if a \fBgenerate\fR callback is specified\&.
.IP [2]
Use \fBboolean\fR if no \fBdefault\fR is specified and the parameter is an option\&.
.IP [3]
Use \fBidentity\fR if no \fBdefault\fR is specified and the parameter is an input\&.
.IP [4]
Use \fBboolean\fR if the specified \fBdefault\fR value is a Tcl boolean\&.
.IP [5]
Use \fBinteger\fR if the specified \fBdefault\fR value is a Tcl integer\&.
.IP [6]
Use \fBidentity\fR as fallback of last resort\&.
.PP
.PP
The general concept of validation types was taken from package
\fBsnit\fR, and modified to suit Cmdr\&. Where snit's types
expect only a single method to validate the input we expect all types
to support an ensemble of \fIfour\fR methods\&. One for the basic
validation and transformation of the input, another for the release of
any internal representation so generated, plus two more for delivery
of a default representation and support for command line completion\&.
The details (method names, signatures, etc\&.) can be found in section
\fBAPI\fR below\&.
.PP
As an example the implementation of the standard boolean
validation type is shown in section \fBExample\fR\&.
.PP
It should be noted that while snit's validation types in
principle allow for the transformation of input into a disparate
internal representation, they never went so far as to allow complex
representations which might require the release of resources after
use\&.
.PP
The \fBvalidate\fR and \fBrelease\fR methods are primarily used
during either completion or execution phases, depending on the chosendeferal state\&. They may also be used during parsing, for optional
inputs under the \fBtest\fR-regime]\&.
.PP
The \fBcomplete\fR method will be used whereever the system
activates an interactive command line shell where arguments may be
assigned to parameters\&.
.PP
The \fBdefault\fR method on the other hand can expect to be
invoked during dispatch, as part of the system's declaration
processing, if not preempted by \fBdefault\fR and \fBgenerate\fR
declarations for the parameter\&. Note here that the \fBdefault\fRmethod has the same signature as a \fBgenerate\fR callback and can be
used as such\&. This is actually needed and useful when the default
internal representation for a validation type cannot be expressed as a
fixed value and its creation while parsing the specification itself is
too early\&. We can still use the validation type for its generation, by
hooking it explicitly into \fBgenerate\fR to change the timing of its
invokation\&.
.SH API
In the descriptions below the \fBcmd\fR is a placeholder for the
actual command prefix, most often a main command, of the validation
type\&.
.TP
\fBcmd\fR \fBcomplete\fR \fIp\fR \fIx\fR
This method is invoked during command completion done by the framework\&.
.sp
It has to return the list of legal string representations for
the type and parameter instance \fIp\fR which have the incomplete word
\fIx\fR as their prefix\&.
.RS
.TP
................................................................................
process\&. While the standard validation types do not make use of it a
custom type may have need for access to the context of the completion\&.
.TP
string \fIx\fR
The string value to complete\&.
.RE
.TP
\fBcmd\fR \fBdefault\fR \fIp\fR
This method is invoked when the framework has to determine the
internal representation of a parameter which has no user-specified
string representation\&.
.sp
It has to return the default internal representation for
the type and parameter instance \fIp\fR\&.
.RS
................................................................................
do not make use of it a custom type may have need for access to the
context\&.
.TP
string \fIx\fR
The string value to complete\&.
.RE
.TP
\fBcmd\fR \fBrelease\fR \fIp\fR \fIx\fR
This method is invoked when the framework has to get rid of an
internal representation for a parameter\&.
.sp
It has to release any resources associated with the internal
representation \fIx\fR of parameter instance \fIp\fR\&.
.sp
Note that the result of this method, if there is any, is
................................................................................
make use of it a custom type may have need for access to the context
of the completion\&.
.TP
string \fIx\fR
The internal representation to release\&.
.RE
.TP
\fBcmd\fR \fBvalidate\fR \fIp\fR \fIx\fR
This method is invoked during to validate and convert a string
representation\&.
.sp
It has to verify that \fIx\fR is a legal string representation
for the parameter instance \fIp\fR, and return the associated internal
representation\&.
.RS

.TH "cmdr_vtypes" n 0 doc "Cmdr, a framework for command line parsing and dispatch"
.BS
.SH NAME
cmdr_vtypes \- Cmdr - Writing custom validation types
.SH SYNOPSIS
package require \fBcmdr::validate \fR
.sp
\fB<v-type>\fR \fBcomplete\fR \fIp\fR \fIx\fR
.sp
\fB<v-type>\fR \fBdefault\fR \fIp\fR
.sp
\fB<v-type>\fR \fBrelease\fR \fIp\fR \fIx\fR
.sp
\fB<v-type>\fR \fBvalidate\fR \fIp\fR \fIx\fR
.sp
.BE
.SH DESCRIPTION
.PP
Welcome to the Cmdr project, written by Andreas Kupries\&.
.PP
For availability please read \fICmdr - How To Get The Sources\fR\&.
.PP
This document describes the API expected of \fIvalidation types\fR
to make them usable within the Cmdr framework, and how to
write a custom validation type\&.
.PP
Readers interested in the standard validation types of the
framework should read \fICmdr - Standard validation types for parameters\fR\&.
.SH BACKGROUND
Validation types are Cmdr's answer to the necessity of moving
between the string and internal representations of
\fBcmdr::parameter\fR instances\&.
................................................................................
Because of the same necessity all parameters must have a
validation type assigned to them, and the framework will choose which,
if the user did not\&. This choice is made per the six rules below and
always returns one of the builtins described in \fICmdr - Standard validation types for parameters\fR\&.
.IP [1]
Use \fBidentity\fR if a \fBgenerate\fR callback is specified\&.
.IP [2]
Use \fBboolean\fR if no \fBdefault\fR is specified and the parameter is an \fIoption\fR\&.
.IP [3]
Use \fBidentity\fR if no \fBdefault\fR is specified and the parameter is an \fIinput\fR\&.
.IP [4]
Use \fBboolean\fR if the specified \fBdefault\fR value is a Tcl boolean\&.
.IP [5]
Use \fBinteger\fR if the specified \fBdefault\fR value is a Tcl integer\&.
.IP [6]
Use \fBidentity\fR as fallback of last resort\&.
.PP
.PP
The general concept of \fIvalidation types\fR was taken frompackage \fBsnit\fR, and modified to suit Cmdr\&.
Where \fBsnit\fR's types expect only a single method to validate
the input we expect all types to support an ensemble of \fIfour\fR
methods\&.One for the basic validation and transformation of the string, anotherfor the release of any internal representation so generated, plus two
more for delivery of a default representation and support for command
line completion\&.
The details (method names, signatures, etc\&.) can be found in section
\fBAPI\fR below\&.
.PP
As an example the implementation of the standard boolean
validation type is shown in section \fBExample\fR\&.
.PP
It should be noted that while \fBsnit\fR's validation types
in principle allow for the transformation of input into a disparate
internal representation, they never went so far as to allow complex
representations which might require the release of resources after
use\&.
.PP
The \fBvalidate\fR and \fBrelease\fR methods are primarily used
during either \fICompletion\fR or \fIExecution\fR phases, depending
on the chosen deferal state\&.
They may also be used during the \fIParsing\fR phase, for optional
\fIinputs\fR under the \fBtest\fR-regime]\&.
.PP
The \fBcomplete\fR method will be used whereever the system
activates an interactive command line shell where arguments may be
assigned to parameters\&.
.PP
The \fBdefault\fR method on the other hand can expect to be
invoked during the \fIDispatch\fR phase, as part of the system's
declaration processing, if not preempted by \fBdefault\fR and
\fBgenerate\fR declarations for the parameter\&.
Note here that the \fBdefault\fR method has the same signature as aparamete's \fBgenerate\fR callback and can be used as such\&.
This is actually needed and useful when the default internal
representation for a validation type cannot be expressed as a fixed
value and its creation while parsing the specification itself is tooearly\&.
We can still use the validation type for its generation, by hooking it
explicitly into \fBgenerate\fR to change the timing of its invokation\&.
.SH API
In the descriptions below the \fB<v-type>\fR is a placeholder for the
actual command prefix, most often a main command, of the validation
type\&.
.TP
\fB<v-type>\fR \fBcomplete\fR \fIp\fR \fIx\fR
This method is invoked during command completion done by the framework\&.
.sp
It has to return the list of legal string representations for
the type and parameter instance \fIp\fR which have the incomplete word
\fIx\fR as their prefix\&.
.RS
.TP
................................................................................
process\&. While the standard validation types do not make use of it a
custom type may have need for access to the context of the completion\&.
.TP
string \fIx\fR
The string value to complete\&.
.RE
.TP
\fB<v-type>\fR \fBdefault\fR \fIp\fR
This method is invoked when the framework has to determine the
internal representation of a parameter which has no user-specified
string representation\&.
.sp
It has to return the default internal representation for
the type and parameter instance \fIp\fR\&.
.RS
................................................................................
do not make use of it a custom type may have need for access to the
context\&.
.TP
string \fIx\fR
The string value to complete\&.
.RE
.TP
\fB<v-type>\fR \fBrelease\fR \fIp\fR \fIx\fR
This method is invoked when the framework has to get rid of an
internal representation for a parameter\&.
.sp
It has to release any resources associated with the internal
representation \fIx\fR of parameter instance \fIp\fR\&.
.sp
Note that the result of this method, if there is any, is
................................................................................
make use of it a custom type may have need for access to the context
of the completion\&.
.TP
string \fIx\fR
The internal representation to release\&.
.RE
.TP
\fB<v-type>\fR \fBvalidate\fR \fIp\fR \fIx\fR
This method is invoked during to validate and convert a string
representation\&.
.sp
It has to verify that \fIx\fR is a legal string representation
for the parameter instance \fIp\fR, and return the associated internal
representation\&.
.RS

<a href="../../../../../../home">Home</a>
| <a href="../../toc.html">Main Table Of Contents</a>
| <a href="../toc.html">Table Of Contents</a>
| <a href="../../index.html">Keyword Index</a>
] <hr>
<h1 class="title">cmdr_dsl(n) 0 doc &quot;Cmdr, a framework for command line parsing and dispatch&quot;</h1>
<div id="name" class="section"><h2><a name="name">Name</a></h2>
<p>cmdr_dsl - Cmdr - Specification Language</p>
</div>
<div id="toc" class="section"><h2><a name="toc">Table Of Contents</a></h2>
<ul class="toc">
<li class="section"><a href="#toc">Table Of Contents</a></li>
<li class="section"><a href="#section1">Description</a></li>
<li class="section"><a href="#section2">Introductory examples</a>
<ul><li class="subsection"><a href="#subsection1">Basic setup, private with inputs</a></li><li class="subsection"><a href="#subsection2">Basic setup, command nesting</a></li></ul></li>
<li class="section"><a href="#section3">Language Reference</a>
<ul>
<li class="subsection"><a href="#subsection3">General</a></li>
<li class="subsection"><a href="#subsection4">Officers</a></li>
<li class="subsection"><a href="#subsection5">Privates</a></li><li class="subsection"><a href="#subsection6">Parameters</a></li>
</ul>
</li>
<li class="section"><a href="#section4">Related Documents</a></li>
<li class="section"><a href="#section5">Bugs, Ideas, Feedback</a></li>
<li class="section"><a href="#keywords">Keywords</a></li>
<li class="section"><a href="#copyright">Copyright</a></li>
</ul>
</div>
<div id="section1" class="section"><h2><a name="section1">Description</a></h2>
<p>Welcome to the Cmdr project, written by Andreas Kupries.</p>
<p>For availability please read <i class="term"><a href="cmdr_howto_get_sources.html">Cmdr - How To Get The Sources</a></i>.</p>
<p>This document is for users of the cmdr framework. It describes the
domain-specific language for the specification of command hierarchies
with commands and their parameters (options, and inputs).</p>
</div>
<div id="section2" class="section"><h2><a name="section2">Introductory examples</a></h2>
<p>Instead of immediately diving into the full syntax of the
specification language first a few examples to demonstrate the general
look and feel, plus basic features.</p>
<div id="subsection1" class="subsection"><h3><a name="subsection1">Basic setup, private with inputs</a></h3>
<p>This example specifies a command line providing 3 commands for
the management of command aliases.
This is actually a slice of <b class="syscmd">stackato</b>'s interface, reduced and
modified to fit here.
While it does not have the necessary backend procedures required to
actually run the commands, it is enough to demonstrate basic features,
namely the declaration of &quot;privates&quot; with &quot;input&quot; parameters.</p>
................................................................................
exit
</pre>
<p>At the bottom of the example, just above we can also see the
very simple Tcl command which invokes the command line processing for
a list of words, here coming from <b class="variable">$argv</b>, i.e. the application's
command line.</p>
</div>
<div id="subsection2" class="subsection"><h3><a name="subsection2">Basic setup, command nesting</a></h3>
<p>The decoupling of command names from their implementations seen
in the previous example makes it easy to re-arrange and re-label the
user visible commands without having to touch any other part of the
code.</p>
<p>This is demonstrated in the example below, moving the 3
&quot;privates&quot; into an &quot;officer&quot; and renaming them, without changing the
actions. Note that the parameter specifications were removed for
................................................................................
} ::foo::backend::alias::list
}
}
...
</pre>
</div>
</div>
<div id="section3" class="section"><h2><a name="section3">Language Reference</a></h2>
<p>With the examples behind us we can now go and specify the entire
specification language. If you have skipped here on first reading,
ignoring the examples, please go back and read them first.</p>
<div id="subsection3" class="subsection"><h3><a name="subsection3">General</a></h3>
<p>The conceptual model underneath the command hierarchy is that
of a tree.</p>
<p>The inner nodes of the tree represent command ensembles, here
called &quot;officer&quot;s. Each officer knows one or more commands, and
delegates actual execution to their respective specification, which
may be another officer, or a private.</p>
<p>The leaf nodes of the tree represent the individual commands,
here called &quot;private&quot;s. Each private is responsible for a singleaction, and knows how to perform it and the parameters used toconfigure that action at runtime.</p>
<p>The same model is graphically presented in the
Entity-Relationship-Diagram below.
<img alt="erd" src="../../image/erd.png"></p>
<p>The &quot;Actor&quot; in that diagram is the common base class for the
ensembles and commands and not directly relevant to users.</p>
<p>The &quot;Config&quot; on the other hand is the second interface seen by
the user, as the sole argument to the action command prefix of
<b class="cmd">private</b> (See section <b class="sectref">Officer</b>).
This container holds all the declared parameters of the command the
action is invoked for, and provides easy access to them through its
methods (see package <b class="package">cmdr::config</b>) at the time of execution.</p></div><div id="subsection4" class="subsection"><h3><a name="subsection4">Officers</a></h3><pre class="example">alias &lt;name&gt; = &lt;name'&gt;... Declare an alternate name for a command path.alias &lt;name&gt; Declare an alternate name for the previous command.common &lt;name&gt; &lt;script&gt; Declare a named shared code block.default Set last command as default.description &lt;text&gt; Set help text for the current ensemble.ehandler &lt;cmdprefix&gt; Execution Interposition.officer &lt;name&gt; &lt;script&gt; Declare a nested ensemble = sub-officerprivate &lt;name&gt; &lt;script&gt; &lt;cmdprefix&gt; Declare a simple command = privateundocumented Hide ensemble from help.</pre><dl class="definitions"><dt><b class="cmd">alias</b> <i class="arg">name</i> <b class="const">=</b> <i class="arg">name'</i>...</dt><dd></dd><dt><b class="cmd">alias</b> <i class="arg">name</i></dt><dd><p>This is a structuring command, for the command hierarchy. Its mainuses are the creation of alternate command names, and of shortcutsthrough the command hierarchy.</p><p>For example, stackato's command specification for alias management ismore like <span class="sectref"><a href="#subsection2">Basic setup, command nesting</a></span> and uses shortcutssimilar to what is shown in--TODO--(example ls-alias2)-- to provide the look of a flat namespace.</p><p>In the first form the <i class="arg">name</i> is given the explicit path tothe command it is an alias for. In the second form it implicitlyrefers to the immediately preceding officer or private.Note that &quot;immediately&quot; is interpreted at the current level. Thesystem is <em>not</em> looking into a nested specification for its lastcommand.</p></dd><dt><b class="cmd">common</b> <i class="arg">name</i> <i class="arg">text</i></dt><dd><p>This is another structuring command, for structuring the specificationitself instead of the command tree it declares.</p><p>It creates named values, usually code blocks, which can beshared between specifications. Note that while each block is visiblein the current officer and its subordinates, parents and siblings haveno access.</p><p>An example of such a block would be</p><pre class="example">common *all* { option debug { Activate client internal tracing. } { undocumented list when-complete [lambda {p tags} { foreach t $tags { debug on $t } }] }}</pre><p>This example defines an option to access the subsystem for debugnarative (See package <b class="package">Tcllib</b>). The example is actually special, as the block named <b class="const">*all*</b> isreserved by the framework. This block, if defined, is automaticallyincluded at the front of all &quot;private&quot; specifications, i.e. sharedacross all the specified commands underneath this officer. A veryimportant trait for the option in the example, as it makes the debugsetup available to all commands without having to explicitly includethe block, and possibly forgetting such.</p><p>Generally speaking, the framework reserves all blocks whosename begins with a star, i.e <b class="const">*</b>, for its own use.</p></dd><dt><b class="cmd">default</b></dt><dd><p>This command sets up a special kind of alias. The last &quot;private&quot; or&quot;officer&quot; is set as the default command to use at runtime.This means that if during &quot;Dispatch&quot; the currently processed word doesnot match any of the commands known to this officer this default isused. If no default is specified an error will be thrown instead.</p></dd><dt><b class="cmd">description</b> <i class="arg">text</i></dt><dd><p>This command declares the help text of the officer.</p></dd><dt><b class="cmd">ehandler</b> <i class="arg">cmdprefix</i></dt><dd><p>This is an advanced command which should normally only be specified atthe top of the whole hierarchy (from which its value willautomatically propagate to all subordinates).</p><p>At runtime the framework will call the specified command prefixwith a single argument, a script whose execution is equivalent to thephases &quot;Parsing&quot;, &quot;Completion&quot;, and &quot;Execution&quot; of the framework, asdescribed in section --TODO--(sectref:flow/phases)--. The handler <em>must</em>call this script, and can perform any application-specific actionsbefore and after.</p><p>This handler's main uses are two-fold:</p><ol class="enumerated"><li><p>Capture and hande application-specific errors which should notabort the application, or shown as Tcl stacktrace.</p></li><li><p>Cleanup of application-specific transient settings theparameter callbacks and/or command implementations may have set duringtheir execution. This is especially important if the interactivecommand line shells of the framework are active. Without such ahandler and its bespoke cleanup code transient settings will leakbetween multiple commands run from such a shell, something which isdefinitely not wanted.</p></li></ol></dd><dt><b class="cmd">officer</b> <i class="arg">name</i> <i class="arg">script</i></dt><dd><p>This command creates a named subordinate officer with itsspecification <i class="arg">script</i> of officer commands as described here.</p></dd><dt><b class="cmd">private</b> <i class="arg">name</i> <i class="arg">script</i> <i class="arg">cmdprefix</i></dt><dd><p>This command creates a named subordinate private with itsspecification <i class="arg">script</i> of private commands as described in thefollowing section, and a command prefix to invoke when it is chosen.</p><p>This command prefix is called with a single argument, the<b class="package">cmdr::config</b> instance holding the parameters of the private.--TODO--(ref:backend-example-code)--</p></dd><dt><b class="cmd">undocumented</b></dt><dd><p>Use of this command influences the generation of help, excluding allofficers having this marker (and their subordinates) from thehelp. Note that subordinates reachable through aliases may beincluded, under the alias name, if not explicitly excluded themselves.</p></dd></dl></div><div id="subsection5" class="subsection"><h3><a name="subsection5">Privates</a></h3><p>The specification of simple commands, i.e. &quot;privates&quot; is quiteeasy, with only seven commands (see the table below). The importantparts are found in the parameter specifications, explained in the nextsection.</p>
<pre class="example">description &lt;text&gt; Set help text for command.input &lt;name&gt; &lt;help&gt; &lt;script&gt; Declare a positional parameter.interactive Allow interactive shell.option &lt;name&gt; &lt;help&gt; &lt;script&gt; Declare a named parameter.state &lt;name&gt; &lt;help&gt; &lt;script&gt; Declare a hidden parameter.undocumented Hide command from help.use &lt;name&gt; Execute the named &quot;common&quot; block here.</pre><dl class="definitions"><dt><b class="cmd">description</b> <i class="arg">text</i></dt><dd><p>Like the equivalent command for <span class="sectref"><a href="#subsection4">Officers</a></span> this commanddeclares the help text for the private.</p></dd><dt><b class="cmd">input</b> <i class="arg">name</i> <i class="arg">help</i> <i class="arg">script</i></dt><dd><p>This command adds an &quot;input&quot; (positional) parameter to the &quot;private&quot;,with description <i class="arg">help</i> and its specification <i class="arg">script</i> ofparameter commands as described in the following section.</p></dd><dt><b class="cmd">interactive</b></dt><dd><p>This command influences the runtime. By default the only interactivecommand line shells are associated with the officers. Setting thismarker activates such a shell for the private, to be invoked whenrequired parameters do not have a value.</p><p>The global command <b class="cmd">cmdr::config interactive</b> in package<b class="package">cmdr::config</b> can be used to globally activate this type ofshell for all &quot;privates&quot;.</p></dd><dt><b class="cmd">option</b> <i class="arg">name</i> <i class="arg">help</i> <i class="arg">script</i></dt><dd><p>This command adds an &quot;option&quot; (named) parameter to the &quot;private&quot;, withdescription <i class="arg">help</i> and its specification <i class="arg">script</i> of parametercommands as described in the following section.</p></dd><dt><b class="cmd">state</b> <i class="arg">name</i> <i class="arg">help</i> <i class="arg">script</i></dt><dd><p>This command adds a &quot;state&quot; (hidden) parameter to the &quot;private&quot;, withdescription <i class="arg">help</i> and its specification <i class="arg">script</i> of parametercommands as described in the following section.</p></dd><dt><b class="cmd">undocumented</b></dt><dd><p>Like the equivalent command for <span class="sectref"><a href="#subsection4">Officers</a></span> use of this commandinfluences the generation of help, excluding all privates having thismarker from it.</p></dd><dt><b class="cmd">use</b> <i class="arg">name</i></dt><dd><p>This command is the counterpart to <b class="cmd">common</b> of <span class="sectref"><a href="#subsection4">Officers</a></span>.It inserts the named block into the specification, executing it. Assuch it expects the contents to be a script of private commands asdescribed in this section.</p></dd></dl>
</div>
<div id="subsection6" class="subsection"><h3><a name="subsection6">Parameters</a></h3><p>The parameters of private commands are the heart of the system,providing the space needed to transfer the command arguments to theimplementations, and having the most attributes controlling theirbehaviour.</p><p>This complexity is mitigated strongly by the use of sensibledefaults for each of the three possible kinds of parameter, i.e.positional &quot;inputs&quot;, named &quot;options&quot;, and &quot;state&quot; hidden from thecommand line.</p><p>Each kind has its own construction command in the DSL for<span class="sectref"><a href="#subsection5">Privates</a></span> which specifies the common information which cannothave defaults, i.e.</p><ol class="enumerated"><li><p>the name identifying it to the system,</p></li><li><p>the help text describing it in informal speech, and, of course,</p></li><li><p>the parameter specification itself, using the commands of this section.</p></li></ol><pre class="example">alias &lt;name&gt; N Declare alternate flag for an option.default &lt;value&gt; R Set constant default value.defered R Defer calculation of the internal representation until demanded.generate &lt;cmdprefix&gt; R Set callback returning the default value.immediate R Complement of defered.interact ?&lt;prompt&gt;? R Enable the interactive entry of the string value.label &lt;text&gt; N Name to use in the help, and as primary flag (for an option).list R Declare as list-valued.optional G Declare input as optional.presence V Declare as boolean option without argument.test G Control the matching of words to optional inputs.undocumented G Declare as hidden from help.validate &lt;cmdprefix&gt; V Declare validation type.when-complete &lt;cmdprefix&gt; C Set callback executed when the value becomes known.when-set &lt;cmdprefix&gt; C Set callback executed when the string value becomes known.</pre><p><em>Naming</em></p><p>We have two commands to influence the visible naming of allparameters.</p><p>As background, all parameters are named for properidentification within the framework and other Tcl code, i.e. thevarious callbacks, including a &quot;private&quot;s action. This &quot;system name&quot;has to be unique within the &quot;private&quot; a parameter belongs to. Beyondthat however the visible parameters have to be identified within helptexts, and, in case of &quot;options&quot;, for detection during &quot;Parsing&quot;. Thatis the visible naming, seen by a user of any application whose commandline processing is based on the Cmdr framework.</p><dl class="definitions"><dt><b class="cmd">label</b> <i class="arg">text</i></dt><dd><p>This command declares the visible name, if different from the systemname used as the default. Note that in most cases this default is goodenough, obviating the need for this command.</p><p>The only use case seen so far is when two semanticallyequivalent input and option parameters clash, requiring differentinternal names due to the requirement for uniqueness, yet also thesame visible name and flag within the help to highlight theirconnection and equivalence.</p></dd><dt><b class="cmd">alias</b> <i class="arg">name</i></dt><dd><p>For option parameters the &quot;label&quot; command and its default specifiesthe name of the primary flag recognized during parsing. If that is notenough for a specific option this command allows the specification ofany number additional flags to be recognized.</p><p>Note however that the framework automatically recognizes notonly the specified flags, but also all unique prefixes, obviating theneed for this command in many cases.</p></dd></dl><p><em>General control</em></p><p>The general handling of a parameter is influenced by threecommands.</p><dl class="definitions"><dt><b class="cmd">optional</b></dt><dd><p>This command marks the parameter as optional, i.e. as something theuser may skip on the command line, and the application supplyingsensible defaults. --TODO--(sectref:para/vtype)--During parsing the framework will then expend some effort to determinewhether an argument word should be assigned to the parameter, or not.</p><p>This setting is only applicable to &quot;inputs&quot;, as &quot;options&quot; areoptional by definition, and &quot;state&quot; is hidden.</p></dd><dt><b class="cmd">test</b></dt><dd><p>This command is related to the above, switching from the standardregime for acceptance based on counting and thresholds to a differentone based on validation. The details are explained in section--TODO--(sectref:flow/parsing, flow/optional)--.</p></dd><dt><b class="cmd">undocumented</b></dt><dd><p>Like &quot;officers&quot; and &quot;privates&quot; parameters can be hidden from thegenerated help. This is the command for doing so, the same as for thefirst two.</p><p>The main use case is the hiding of options giving anapplication developer access to the internals of their application,something a regular user has no need of, and doesn't have to knowabout.</p></dd></dl><p><em>Representations</em></p><p>An important concept of parameters is something taken up fromTcl itself.The differentation between string and internal representations.Where Tcl uses internal representations to speed up its execution herethis separation is that of between the information delivered to theapplication by a user, and the application-specific data structuresbehind them.</p><p>All parameters will have an internal representation.This is usually derived from the string representation provided by theuser.The details of that process are explained in section--TODO--(sectref:para/vtype)--about validation types.However we have cases where the user cannot specify a stringrepresentation (&quot;states&quot;), or is allowed to choose not to (optional&quot;inputs&quot;, &quot;options&quot;).For these cases three specification commands are made availableenabling us to programmatically choose the internal representation.</p><dl class="definitions"><dt><b class="cmd">default</b> <i class="arg">value</i></dt><dd><p>This command provides a constant value for the internalrepresentation.</p></dd><dt><b class="cmd">generate</b> <i class="arg">cmdprefix</i></dt><dd><p>This command provides a callback to compute the internalrepresentation at runtime. This is useful if the default is somethingwhich cannot be captured as a fixed value, for example a handle tosome resource, or a dynamically created object.</p><p>The command prefix is invoked with a single argument, the<b class="package">cmdr::parameter</b> instance for which to generate the internalrepresentation.</p></dd></dl><p>The commands &quot;default&quot; and &quot;generate&quot; exclude each other,i.e. only of them can be specified.If neither are specified, and we need a default (see the casesabove) a default is chosen per the two rules below:</p><ol class="enumerated"><li><p>Use the empty string for a &quot;list&quot; parameter.</p></li><li><p>Use the default value supplied by the chosen validation type (See section --TODO--(sectref:para/vtype)--).</p></li></ol><dl class="definitions"><dt><b class="cmd">interact</b> <span class="opt">?<i class="arg">prompt</i>?</span></dt><dd><p>This command actually does not specify an internal representation, butactivates another method for the user to specify a string value forthe parameter, outside of the command line. As such it has priority over either &quot;default&quot; and &quot;generate,&quot; and canbe specified with either. A parameter marked with it willinteractively ask the user for a value if none was specified on thecommand line.</p><p>The default <i class="arg">prompt</i> is derived from the system name.</p></dd></dl><p>To recapitulate:</p><ol class="enumerated"><li><p>A string representation specified on the command line has the highest priority and goes through the chosen validation type to get the associated internal representation.</p></li><li><p>If activated via &quot;interact&quot; a small shell is run asking the user for a value (or more, as per &quot;list&quot;, see below). The result goes through the chosen validation type to get the associated internal representation.</p></li><li><p>After that the internal representation is either the declared &quot;default,&quot; or the result of invoking the &quot;generate&quot; callback. As internal representations they are <em>not</em> run through the chosen validation type.</p></li></ol><dl class="definitions"><dt><b class="cmd">list</b></dt><dd><p>This command is used to mark parameters whose string and thus internalvalue should be treated as a list. By default all parameters are scalar.</p><p>This affects the handling of the parameter during parsing, by&quot;interact&quot; above, and the use of the validation type. The last two askfor multiple values, and feed the elements of the string valueseparately through validation instead of just the string value in one.During parsing treatment of &quot;options&quot; changes from keeping only thelast assigned value to accumulation of all values. Similarly alist-&quot;input&quot; takes all remaining words on the command line for itselfinstead of just the current word. Because of this list-&quot;inputs&quot; areonly allowed as the last parameter of a &quot;private.&quot;</p></dd></dl><p>The last two specification commands dealing with therepresentations control when the internal representation is created.</p><dl class="definitions"><dt><b class="cmd">defered</b></dt><dd><p>This command marks a parameter as defered, with the internalrepresentation computed on first access to its value. This is thedefault for &quot;state&quot; parameters.</p></dd><dt><b class="cmd">immediate</b></dt><dd><p>This command marks a parameter as immediate, with the internalrepresentation computed in the &quot;Completion&quot; phase. This is the defaultfor &quot;input&quot; and &quot;option&quot; parameters.</p></dd></dl><p><em>Validation</em></p><p>The answer to the necessity of moving between the string andinternal representations described in the previous section are thevalidation types. Given a string representation they either return theassociated internal representation or raise an error, signaling thatthe input was illegal. This part of their work, the verification ofthe legality of the input string gave them their name.</p><p>The general concept of validation types was taken from<b class="package">snit</b>, and modified to suit Cmdr. Where snit's typesexpect only a single method to validate the input Cmdrexpects all types to support an ensemble of <em>four</em> methods, onefor the basic validation and transformation of the input, another forthe release of any internal representation so generated, plus deliveryof a default representation and support for command line completion.</p><dl class="definitions"><dt><b class="cmd">validate</b> <i class="arg">cmdprefix</i></dt><dd><p>This command specifies a validation type for the parameter, in theform of a command prefix.The set of methods this callback has to support, their signatures,etc. are all explained in <i class="term"><a href="cmdr_vtypes.html">Cmdr - Writing custom validation types</a></i>. This documentcontains the implementation of the standard boolean validation type asan example as well.</p><p>Because of the same necessity all parameters must have avalidation type assigned to them, and the system will choose which, ifthe user did not. This choice is made per the six rules below andalways returns one of the standard types implemented in package<b class="package">cmdr::validate</b>.</p><ol class="enumerated"><li><p>Use &quot;identity&quot; if a &quot;generate&quot; callback is specified.</p></li><li><p>Use &quot;boolean&quot; if no &quot;default&quot; is specified and the parameter is an option.</p></li><li><p>Use &quot;identity&quot; if no &quot;default&quot; is specified and the parameter is an input.</p></li><li><p>Use &quot;boolean&quot; if the specified &quot;default&quot; value is a Tcl boolean.</p></li><li><p>Use &quot;integer&quot; if the specified &quot;default&quot; value is a Tcl integer.</p></li><li><p>Use &quot;identity&quot; as fallback of last resort.</p></li></ol></dd><dt><b class="cmd">presence</b></dt><dd><p>This command is best discussed as part of the wider area of &quot;boolean&quot;options, i.e. options with validation type &quot;boolean&quot; assigned tothem. These have associated special behaviours, both in the handlingof the specification, and during parsing.</p><p>First, normal boolean options. They have automatic aliasesdeclared for them, derived from their primary flag. An option named&quot;foo&quot; will have an alias of &quot;no-foo&quot;, and the reverse. During parsingthe &quot;foo&quot; and &quot;no-foo&quot; flags have inverse semantics, and both areallowed to occur without option argument following the flag. This isin contrast to all other options which must have such an argument. Theparser essentially uses the validation type to decide if the wordafter the flag is a proper boolean value, or not, i.e. an argument toassign to the parameter, or not.</p><p>Now &quot;presence&quot; declares a variant of the above, a booleanoption without the automatic aliases, and <em>never</em> taking anargument during parsing. Its mere <em>presence</em> on the command linewill set its parameter. Their default value is consequently fixed to<b class="const">false</b> as well.</p></dd></dl><p><em>Signaling</em> Of the four callbacks supported by parameters the first two,&quot;generate&quot; and &quot;validate&quot; have been described already, in the sections--TODO--\ref{para/reps} about representations and--TODO--\ref{para/vtype} about validation types, respectively.</p><p>This section explains the commonalities between the callbacksin general, and the last two, for notifications about state changes indetail.</p><p>All callbacks are treated as command prefixes, notscripts.There are no placeholder substitutions, only arguments added to eachcommand prefix on invokation. This does not harm the generality of thesystem, as complex scripts can be used via procedures or equivalents(i.e. <b class="cmd">apply</b>).</p><p>The two callbacks not yet described are the state-changecallbacks through which the framework can actively drive parts of theapplication while processing the command line, whereas normally theapplication drives access to parameters through their methods.</p><dl class="definitions"><dt><b class="cmd">when-complete</b> <i class="arg">cmdprefix</i></dt><dd><p>This command declares the state-change callback to invoke when theinternal representation of the parameter is generated from the stringrepresentation, or the various ways of getting a default.</p><p>The callback is invoked with two arguments, the<b class="package">cmdr::parameter</b> instance of the parameter which changed, andits internal representation, in this order.</p></dd><dt><b class="cmd">when-set</b> <i class="arg">cmdprefix</i></dt><dd><p>This command declares the state-change callback to invoke when thestring representation of the parameter is set during command lineparsing.</p><p>The callback is invoked with two arguments, the<b class="package">cmdr::parameter</b> instance of the parameter which changed, andits string representation, in this order.</p></dd></dl><p>Due to their nature these callbacks are invoked at runtime duringeither parsing, completion,&quot; or execution. The details are shown inthe table below. The specification commands influencing the timing,i.e. forcing the use in a specific phase are shown in the intersectionof callback and phase.</p><pre class="example"> | Dispatch | Parsing | Completion | Execution--------------------+----------+---------+-------------+-----------validate (default) | * | | | --------------------+----------+---------+-------------+-----------validate (complete) | | * | immediate | deferedwhen-set | | * | | --------------------+----------+---------+-------------+-----------generate | | | immediate | deferedvalidate (validate) | | test | immediate | deferedvalidate (release) | | test | immediate | defered--------------------+----------+---------+-------------+-----------when-complete | | | immediate | defered--------------------+----------+---------+-------------+-----------</pre></div></div>
<div id="section4" class="section"><h2><a name="section4">Related Documents</a></h2>
<ol class="enumerated">
<li><p><i class="term"><a href="cmdr_introduction.html">Cmdr - Introduction to the project</a></i></p></li>
<li><p><i class="term"><a href="cmdr_license.html">Cmdr - License</a></i></p></li>
<li><p><i class="term"><a href="cmdr_changes.html">Cmdr - Log of Changes</a></i></p></li>
<li><p><i class="term"><a href="cmdr_howto_get_sources.html">Cmdr - How To Get The Sources</a></i></p></li>
<li><p><i class="term"><a href="cmdr_howto_installation.html">Cmdr - The Installer's Guide</a></i></p></li>
<li><p><i class="term"><a href="cmdr_howto_development.html">Cmdr - The Developer's Guide</a></i></p></li>
</ol>
</div>
<div id="section5" class="section"><h2><a name="section5">Bugs, Ideas, Feedback</a></h2>
<p>Both the package(s) and this documentation will undoubtedly contain
bugs and other problems.
Please report such at
<a href="https:/core.tcl.tk/akupries/cmdr">Cmdr Tickets</a>.</p>
<p>Please also report any ideas you may have for enhancements of
either package(s) and/or documentation.</p>
</div>

<a href="../../../../../../home">Home</a>
| <a href="../../toc.html">Main Table Of Contents</a>
| <a href="../toc.html">Table Of Contents</a>
| <a href="../../index.html">Keyword Index</a>
] <hr>
<h1 class="title">cmdr_dsl(n) 0 doc &quot;Cmdr, a framework for command line parsing and dispatch&quot;</h1>
<div id="name" class="section"><h2><a name="name">Name</a></h2>
<p>cmdr_dsl - Cmdr - Introduction to the Specification Language</p>
</div>
<div id="toc" class="section"><h2><a name="toc">Table Of Contents</a></h2>
<ul class="toc">
<li class="section"><a href="#toc">Table Of Contents</a></li>
<li class="section"><a href="#section1">Description</a></li>
<li class="section"><a href="#section2">Related Specification Documents</a></li>
<li class="section"><a href="#section3">Introductory examples</a>
<ul>
<li class="subsection"><a href="#subsection1">Basic private commands with inputs</a></li>
<li class="subsection"><a href="#subsection2">Simple command nesting</a></li>
</ul>
</li>
<li class="section"><a href="#section4">Language Reference</a></li>
<li class="section"><a href="#section5">Related Documents</a></li>
<li class="section"><a href="#section6">Bugs, Ideas, Feedback</a></li>
<li class="section"><a href="#keywords">Keywords</a></li>
<li class="section"><a href="#copyright">Copyright</a></li>
</ul>
</div>
<div id="section1" class="section"><h2><a name="section1">Description</a></h2>
<p>Welcome to the Cmdr project, written by Andreas Kupries.</p>
<p>For availability please read <i class="term"><a href="cmdr_howto_get_sources.html">Cmdr - How To Get The Sources</a></i>.</p>
<p>This document is for users of the cmdr framework. It introduces the
domain-specific language for the specification of command hierarchies
with commands and their parameters by way of examples and thenprovides links to the detailed reference documents.</p>
</div>
<div id="section2" class="section"><h2><a name="section2">Related Specification Documents</a></h2>
<ol class="enumerated"><li><p><i class="term">Cmdr - Introduction to the Specification Language</i></p></li><li><p><i class="term"><a href="cmdr_dsl_officer.html">Cmdr - Officer Specification Language</a></i></p></li><li><p><i class="term"><a href="cmdr_dsl_private.html">Cmdr - Private Specification Language</a></i></p></li><li><p><i class="term"><a href="cmdr_dsl_parameter.html">Cmdr - Parameter Specification Language</a></i></p></li></ol></div><div id="section3" class="section"><h2><a name="section3">Introductory examples</a></h2>
<p>Instead of immediately diving into the full syntax of the
specification language first a few examples to demonstrate the general
look and feel, plus basic features.</p>
<div id="subsection1" class="subsection"><h3><a name="subsection1">Basic private commands with inputs</a></h3>
<p>This example specifies a command line providing 3 commands for
the management of command aliases.
This is actually a slice of <b class="syscmd">stackato</b>'s interface, reduced and
modified to fit here.
While it does not have the necessary backend procedures required to
actually run the commands, it is enough to demonstrate basic features,
namely the declaration of &quot;privates&quot; with &quot;input&quot; parameters.</p>
................................................................................
exit
</pre>
<p>At the bottom of the example, just above we can also see the
very simple Tcl command which invokes the command line processing for
a list of words, here coming from <b class="variable">$argv</b>, i.e. the application's
command line.</p>
</div>
<div id="subsection2" class="subsection"><h3><a name="subsection2">Simple command nesting</a></h3>
<p>The decoupling of command names from their implementations seen
in the previous example makes it easy to re-arrange and re-label the
user visible commands without having to touch any other part of the
code.</p>
<p>This is demonstrated in the example below, moving the 3
&quot;privates&quot; into an &quot;officer&quot; and renaming them, without changing the
actions. Note that the parameter specifications were removed for
................................................................................
} ::foo::backend::alias::list
}
}
...
</pre>
</div>
</div>
<div id="section4" class="section"><h2><a name="section4">Language Reference</a></h2>
<p>With the examples behind us we can now go and specify the entire
specification language. If you have skipped here on first reading,
ignoring the examples, please go back and read them first.</p>
<p>The conceptual model underneath the command hierarchy is that
of a tree.</p>
<p>The inner nodes of the tree represent command ensembles, here
called <i class="term">officer</i>s. Each officer knows one or more commands toperform, and delegates actual execution to their respective
specification, which may be another <i class="term">officer</i>, or a <i class="term">private</i>.</p>
<p>The leaf nodes of the tree represent the individual commands,
here called <i class="term">private</i>s.Each <i class="term">private</i> is responsible for a single action and knows howto perform it, and the set of <i class="term">parameter</i>s used to configure that
action at runtime.</p>
<p>The same model is graphically presented in the
Entity-Relationship-Diagram below.
<img alt="erd" src="../../image/erd.png"></p>
<p>The <i class="term">actor</i> in that diagram is the common base class for the
ensembles and commands and not directly relevant to users.</p>
<p>The <i class="term">config</i> on the other hand is the second interface
seen by the user, as the sole argument to the action command prefix of
<b class="cmd">private</b>. See <i class="term"><a href="cmdr_dsl_officer.html">Cmdr - Officer Specification Language</a></i> for the details.
This container, an instance of <b class="package"><a href="cmdr_config.html">cmdr::config</a></b>, holds all the
declared parameters of the command the action is invoked for, and
provides easy access to them through its methods at the time ofexecution.</p>
<p>Please continue reading with <i class="term"><a href="cmdr_dsl_officer.html">Cmdr - Officer Specification Language</a></i>.</p>
</div>
<div id="section5" class="section"><h2><a name="section5">Related Documents</a></h2>
<ol class="enumerated">
<li><p><i class="term"><a href="cmdr_introduction.html">Cmdr - Introduction to the project</a></i></p></li>
<li><p><i class="term"><a href="cmdr_license.html">Cmdr - License</a></i></p></li>
<li><p><i class="term"><a href="cmdr_changes.html">Cmdr - Log of Changes</a></i></p></li>
<li><p><i class="term"><a href="cmdr_howto_get_sources.html">Cmdr - How To Get The Sources</a></i></p></li>
<li><p><i class="term"><a href="cmdr_howto_installation.html">Cmdr - The Installer's Guide</a></i></p></li>
<li><p><i class="term"><a href="cmdr_howto_development.html">Cmdr - The Developer's Guide</a></i></p></li>
</ol>
</div>
<div id="section6" class="section"><h2><a name="section6">Bugs, Ideas, Feedback</a></h2>
<p>Both the package(s) and this documentation will undoubtedly contain
bugs and other problems.
Please report such at
<a href="https:/core.tcl.tk/akupries/cmdr">Cmdr Tickets</a>.</p>
<p>Please also report any ideas you may have for enhancements of
either package(s) and/or documentation.</p>
</div>

</div>
<div id="synopsis" class="section"><h2><a name="synopsis">Synopsis</a></h2>
<div class="synopsis">
<ul class="requirements">
<li>package require <b class="pkgname">cmdr::validate</b></li>
</ul>
<ul class="syntax">
<li><a href="#1"><b class="cmd">cmd</b> <b class="method">complete</b> <i class="arg">p</i> <i class="arg">x</i></a></li>
<li><a href="#2"><b class="cmd">cmd</b> <b class="method">default</b> <i class="arg">p</i></a></li>
<li><a href="#3"><b class="cmd">cmd</b> <b class="method">release</b> <i class="arg">p</i> <i class="arg">x</i></a></li>
<li><a href="#4"><b class="cmd">cmd</b> <b class="method">validate</b> <i class="arg">p</i> <i class="arg">x</i></a></li>
</ul>
</div>
</div>
<div id="section1" class="section"><h2><a name="section1">Description</a></h2>
<p>Welcome to the Cmdr project, written by Andreas Kupries.</p>
<p>For availability please read <i class="term"><a href="cmdr_howto_get_sources.html">Cmdr - How To Get The Sources</a></i>.</p>
<p>This document describes the API expected of validation types to make
them usable within the Cmdr framework, and how to write a
custom validation type.</p>
<p>Readers interested in the standard validation types of the
framework should read <i class="term"><a href="cmdr_validate.html">Cmdr - Standard validation types for parameters</a></i>.</p>
</div>
<div id="section2" class="section"><h2><a name="section2">Background</a></h2>
<p>Validation types are Cmdr's answer to the necessity of moving
between the string and internal representations of
<b class="package">cmdr::parameter</b> instances.
Given a string representation they either return the associated
internal representation or raise an error, signaling that the input
was illegal. This part of their work, the verification of the legality
of the input string gave them their name.</p>
<p>Because of the same necessity all parameters must have a
validation type assigned to them, and the framework will choose which,
if the user did not. This choice is made per the six rules below and
always returns one of the builtins described in <i class="term"><a href="cmdr_validate.html">Cmdr - Standard validation types for parameters</a></i>.</p>
<ol class="enumerated">
<li><p>Use <b class="const">identity</b> if a <b class="cmd">generate</b> callback is specified.</p></li>
<li><p>Use <b class="const">boolean</b> if no <b class="cmd">default</b> is specified and the parameter is an option.</p></li>
<li><p>Use <b class="const">identity</b> if no <b class="cmd">default</b> is specified and the parameter is an input.</p></li>
<li><p>Use <b class="const">boolean</b> if the specified <b class="cmd">default</b> value is a Tcl boolean.</p></li>
<li><p>Use <b class="const">integer</b> if the specified <b class="cmd">default</b> value is a Tcl integer.</p></li>
<li><p>Use <b class="const">identity</b> as fallback of last resort.</p></li>
</ol>
<p>The general concept of validation types was taken from package
<b class="package">snit</b>, and modified to suit Cmdr. Where snit's types
expect only a single method to validate the input we expect all types
to support an ensemble of <em>four</em> methods. One for the basic
validation and transformation of the input, another for the release of
any internal representation so generated, plus two more for delivery
of a default representation and support for command line completion.
The details (method names, signatures, etc.) can be found in section
<span class="sectref"><a href="#section3">API</a></span> below.</p>
<p>As an example the implementation of the standard boolean
validation type is shown in section <span class="sectref"><a href="#section4">Example</a></span>.</p>
<p>It should be noted that while snit's validation types in
principle allow for the transformation of input into a disparate
internal representation, they never went so far as to allow complex
representations which might require the release of resources after
use.</p>
<p>The <b class="cmd">validate</b> and <b class="cmd">release</b> methods are primarily used
during either completion or execution phases, depending on the chosendeferal state. They may also be used during parsing, for optional
inputs under the <b class="cmd">test</b>-regime].</p>
<p>The <b class="cmd">complete</b> method will be used whereever the system
activates an interactive command line shell where arguments may be
assigned to parameters.</p>
<p>The <b class="cmd">default</b> method on the other hand can expect to be
invoked during dispatch, as part of the system's declaration
processing, if not preempted by <b class="cmd">default</b> and <b class="cmd">generate</b>declarations for the parameter. Note here that the <b class="cmd">default</b>
method has the same signature as a <b class="cmd">generate</b> callback and can be
used as such. This is actually needed and useful when the default
internal representation for a validation type cannot be expressed as a
fixed value and its creation while parsing the specification itself is
too early. We can still use the validation type for its generation, by
hooking it explicitly into <b class="cmd">generate</b> to change the timing of its
invokation.</p>
</div>
<div id="section3" class="section"><h2><a name="section3">API</a></h2>
<p>In the descriptions below the <b class="cmd">cmd</b> is a placeholder for the
actual command prefix, most often a main command, of the validation
type.</p>
<dl class="definitions">
<dt><a name="1"><b class="cmd">cmd</b> <b class="method">complete</b> <i class="arg">p</i> <i class="arg">x</i></a></dt>
<dd><p>This method is invoked during command completion done by the framework.</p>
<p>It has to return the list of legal string representations for
the type and parameter instance <i class="arg">p</i> which have the incomplete word
<i class="arg">x</i> as their prefix.</p>
<dl class="arguments">
<dt><b class="package">cmdr::parameter</b> <i class="arg">p</i></dt>
<dd><p>The <b class="package">cmdr::parameter</b> instance governing the completion
process. While the standard validation types do not make use of it a
custom type may have need for access to the context of the completion.</p></dd>
<dt>string <i class="arg">x</i></dt>
<dd><p>The string value to complete.</p></dd>
</dl></dd>
<dt><a name="2"><b class="cmd">cmd</b> <b class="method">default</b> <i class="arg">p</i></a></dt>
<dd><p>This method is invoked when the framework has to determine the
internal representation of a parameter which has no user-specified
string representation.</p>
<p>It has to return the default internal representation for
the type and parameter instance <i class="arg">p</i>.</p>
<dl class="arguments">
<dt><b class="package">cmdr::parameter</b> <i class="arg">p</i></dt>
<dd><p>The <b class="package">cmdr::parameter</b> instance whose default internal
representation is to be computed. While the standard validation types
do not make use of it a custom type may have need for access to the
context.</p></dd>
<dt>string <i class="arg">x</i></dt>
<dd><p>The string value to complete.</p></dd>
</dl></dd>
<dt><a name="3"><b class="cmd">cmd</b> <b class="method">release</b> <i class="arg">p</i> <i class="arg">x</i></a></dt>
<dd><p>This method is invoked when the framework has to get rid of an
internal representation for a parameter.</p>
<p>It has to release any resources associated with the internal
representation <i class="arg">x</i> of parameter instance <i class="arg">p</i>.</p>
<p>Note that the result of this method, if there is any, is
ignored by the framework.</p>
<dl class="arguments">
<dt><b class="package">cmdr::parameter</b> <i class="arg">p</i></dt>
<dd><p>The <b class="package">cmdr::parameter</b> instance holding the internal
representation to release. While the standard validation types do not
make use of it a custom type may have need for access to the context
of the completion.</p></dd>
<dt>string <i class="arg">x</i></dt>
<dd><p>The internal representation to release.</p></dd>
</dl></dd>
<dt><a name="4"><b class="cmd">cmd</b> <b class="method">validate</b> <i class="arg">p</i> <i class="arg">x</i></a></dt>
<dd><p>This method is invoked during to validate and convert a string
representation.</p>
<p>It has to verify that <i class="arg">x</i> is a legal string representation
for the parameter instance <i class="arg">p</i>, and return the associated internal
representation.</p>
<dl class="arguments">
<dt><b class="package">cmdr::parameter</b> <i class="arg">p</i></dt>
<dd><p>The <b class="package">cmdr::parameter</b> instance governing the validation
process. The standard validation types make use of it in case of a
validation failure to generate a proper error message.
See also <i class="term">Utilities for Validation Types</i> for commands helping
with keeping validation error messages uniform.</p></dd>
<dt>string <i class="arg">x</i></dt>
<dd><p>The string value to validate cand convert.</p></dd>
</dl></dd>

</div>
<div id="synopsis" class="section"><h2><a name="synopsis">Synopsis</a></h2>
<div class="synopsis">
<ul class="requirements">
<li>package require <b class="pkgname">cmdr::validate</b></li>
</ul>
<ul class="syntax">
<li><a href="#1"><b class="cmd">&lt;v-type&gt;</b> <b class="method">complete</b> <i class="arg">p</i> <i class="arg">x</i></a></li>
<li><a href="#2"><b class="cmd">&lt;v-type&gt;</b> <b class="method">default</b> <i class="arg">p</i></a></li>
<li><a href="#3"><b class="cmd">&lt;v-type&gt;</b> <b class="method">release</b> <i class="arg">p</i> <i class="arg">x</i></a></li>
<li><a href="#4"><b class="cmd">&lt;v-type&gt;</b> <b class="method">validate</b> <i class="arg">p</i> <i class="arg">x</i></a></li>
</ul>
</div>
</div>
<div id="section1" class="section"><h2><a name="section1">Description</a></h2>
<p>Welcome to the Cmdr project, written by Andreas Kupries.</p>
<p>For availability please read <i class="term"><a href="cmdr_howto_get_sources.html">Cmdr - How To Get The Sources</a></i>.</p>
<p>This document describes the API expected of <i class="term">validation types</i>
to make them usable within the Cmdr framework, and how to
write a custom validation type.</p>
<p>Readers interested in the standard validation types of the
framework should read <i class="term"><a href="cmdr_validate.html">Cmdr - Standard validation types for parameters</a></i>.</p>
</div>
<div id="section2" class="section"><h2><a name="section2">Background</a></h2>
<p>Validation types are Cmdr's answer to the necessity of moving
between the string and internal representations of
<b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> instances.
Given a string representation they either return the associated
internal representation or raise an error, signaling that the input
was illegal. This part of their work, the verification of the legality
of the input string gave them their name.</p>
<p>Because of the same necessity all parameters must have a
validation type assigned to them, and the framework will choose which,
if the user did not. This choice is made per the six rules below and
always returns one of the builtins described in <i class="term"><a href="cmdr_validate.html">Cmdr - Standard validation types for parameters</a></i>.</p>
<ol class="enumerated">
<li><p>Use <b class="const">identity</b> if a <b class="cmd">generate</b> callback is specified.</p></li>
<li><p>Use <b class="const">boolean</b> if no <b class="cmd">default</b> is specified and the parameter is an <i class="term">option</i>.</p></li>
<li><p>Use <b class="const">identity</b> if no <b class="cmd">default</b> is specified and the parameter is an <i class="term">input</i>.</p></li>
<li><p>Use <b class="const">boolean</b> if the specified <b class="cmd">default</b> value is a Tcl boolean.</p></li>
<li><p>Use <b class="const">integer</b> if the specified <b class="cmd">default</b> value is a Tcl integer.</p></li>
<li><p>Use <b class="const">identity</b> as fallback of last resort.</p></li>
</ol>
<p>The general concept of <i class="term">validation types</i> was taken frompackage <b class="package">snit</b>, and modified to suit Cmdr.
Where <b class="package">snit</b>'s types expect only a single method to validate
the input we expect all types to support an ensemble of <em>four</em>
methods.One for the basic validation and transformation of the string, anotherfor the release of any internal representation so generated, plus two
more for delivery of a default representation and support for command
line completion.
The details (method names, signatures, etc.) can be found in section
<span class="sectref"><a href="#section3">API</a></span> below.</p>
<p>As an example the implementation of the standard boolean
validation type is shown in section <span class="sectref"><a href="#section4">Example</a></span>.</p>
<p>It should be noted that while <b class="package">snit</b>'s validation types
in principle allow for the transformation of input into a disparate
internal representation, they never went so far as to allow complex
representations which might require the release of resources after
use.</p>
<p>The <b class="cmd">validate</b> and <b class="cmd">release</b> methods are primarily used
during either <i class="term">Completion</i> or <i class="term">Execution</i> phases, dependingon the chosen deferal state.
They may also be used during the <i class="term">Parsing</i> phase, for optional
<i class="term">inputs</i> under the <b class="cmd">test</b>-regime].</p>
<p>The <b class="cmd">complete</b> method will be used whereever the system
activates an interactive command line shell where arguments may be
assigned to parameters.</p>
<p>The <b class="cmd">default</b> method on the other hand can expect to be
invoked during the <i class="term">Dispatch</i> phase, as part of the system's
declaration processing, if not preempted by <b class="cmd">default</b> and
<b class="cmd">generate</b> declarations for the parameter.
Note here that the <b class="cmd">default</b> method has the same signature as aparamete's <b class="cmd">generate</b> callback and can be used as such.
This is actually needed and useful when the default internal
representation for a validation type cannot be expressed as a fixed
value and its creation while parsing the specification itself is tooearly.
We can still use the validation type for its generation, by hooking it
explicitly into <b class="cmd">generate</b> to change the timing of its invokation.</p>
</div>
<div id="section3" class="section"><h2><a name="section3">API</a></h2>
<p>In the descriptions below the <b class="cmd">&lt;v-type&gt;</b> is a placeholder for the
actual command prefix, most often a main command, of the validation
type.</p>
<dl class="definitions">
<dt><a name="1"><b class="cmd">&lt;v-type&gt;</b> <b class="method">complete</b> <i class="arg">p</i> <i class="arg">x</i></a></dt>
<dd><p>This method is invoked during command completion done by the framework.</p>
<p>It has to return the list of legal string representations for
the type and parameter instance <i class="arg">p</i> which have the incomplete word
<i class="arg">x</i> as their prefix.</p>
<dl class="arguments">
<dt><b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> <i class="arg">p</i></dt>
<dd><p>The <b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> instance governing the completion
process. While the standard validation types do not make use of it a
custom type may have need for access to the context of the completion.</p></dd>
<dt>string <i class="arg">x</i></dt>
<dd><p>The string value to complete.</p></dd>
</dl></dd>
<dt><a name="2"><b class="cmd">&lt;v-type&gt;</b> <b class="method">default</b> <i class="arg">p</i></a></dt>
<dd><p>This method is invoked when the framework has to determine the
internal representation of a parameter which has no user-specified
string representation.</p>
<p>It has to return the default internal representation for
the type and parameter instance <i class="arg">p</i>.</p>
<dl class="arguments">
<dt><b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> <i class="arg">p</i></dt>
<dd><p>The <b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> instance whose default internal
representation is to be computed. While the standard validation types
do not make use of it a custom type may have need for access to the
context.</p></dd>
<dt>string <i class="arg">x</i></dt>
<dd><p>The string value to complete.</p></dd>
</dl></dd>
<dt><a name="3"><b class="cmd">&lt;v-type&gt;</b> <b class="method">release</b> <i class="arg">p</i> <i class="arg">x</i></a></dt>
<dd><p>This method is invoked when the framework has to get rid of an
internal representation for a parameter.</p>
<p>It has to release any resources associated with the internal
representation <i class="arg">x</i> of parameter instance <i class="arg">p</i>.</p>
<p>Note that the result of this method, if there is any, is
ignored by the framework.</p>
<dl class="arguments">
<dt><b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> <i class="arg">p</i></dt>
<dd><p>The <b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> instance holding the internal
representation to release. While the standard validation types do not
make use of it a custom type may have need for access to the context
of the completion.</p></dd>
<dt>string <i class="arg">x</i></dt>
<dd><p>The internal representation to release.</p></dd>
</dl></dd>
<dt><a name="4"><b class="cmd">&lt;v-type&gt;</b> <b class="method">validate</b> <i class="arg">p</i> <i class="arg">x</i></a></dt>
<dd><p>This method is invoked during to validate and convert a string
representation.</p>
<p>It has to verify that <i class="arg">x</i> is a legal string representation
for the parameter instance <i class="arg">p</i>, and return the associated internal
representation.</p>
<dl class="arguments">
<dt><b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> <i class="arg">p</i></dt>
<dd><p>The <b class="package"><a href="cmdr_parameter.html">cmdr::parameter</a></b> instance governing the validation
process. The standard validation types make use of it in case of a
validation failure to generate a proper error message.
See also <i class="term">Utilities for Validation Types</i> for commands helping
with keeping validation error messages uniform.</p></dd>
<dt>string <i class="arg">x</i></dt>
<dd><p>The string value to validate cand convert.</p></dd>
</dl></dd>