From 477c9c4119df5fd45c1129651922d238dccad8c9 Mon Sep 17 00:00:00 2001 From: "Chris St. Pierre" Date: Tue, 16 Sep 2014 15:50:04 -0700 Subject: testsuite: Added unit tests for new option parsing --- doc/development/option_parsing.txt | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) (limited to 'doc') diff --git a/doc/development/option_parsing.txt b/doc/development/option_parsing.txt index 091f43cdd..642b9a36c 100644 --- a/doc/development/option_parsing.txt +++ b/doc/development/option_parsing.txt @@ -174,28 +174,31 @@ The normal implementation pattern is this: #. Define all of your subcommands as children of :class:`Bcfg2.Options.Subcommand`. -#. Define a :class:`Bcfg2.Options.CommandRegistry` object that will be +#. Create a :class:`Bcfg2.Options.CommandRegistry` object that will be used to register all of the commands. Registering a command collect its options and adds it as a :class:`Bcfg2.Options.Subparser` option group to the main option parser. #. Register your commands with - :func:`Bcfg2.Options.register_commands`, parse options, and run. + :func:`Bcfg2.Options.register_commands`. +#. Add options from the + :attr:`Bcfg2.Options.CommandRegistry.command_options` + attribute to the option parser. +#. Parse options, and run. :mod:`Bcfg2.Server.Admin` provides a fairly simple implementation, -where the CLI class is itself the command registry: +where the CLI class subclasses the command registry: .. code-block:: python class CLI(Bcfg2.Options.CommandRegistry): def __init__(self): Bcfg2.Options.CommandRegistry.__init__(self) - Bcfg2.Options.register_commands(self.__class__, - globals().values(), - parent=AdminCmd) + self.register_commands(globals().values(), parent=AdminCmd) parser = Bcfg2.Options.get_parser( description="Manage a running Bcfg2 server", components=[self]) + parser.add_options(self.subcommand_options) parser.parse() In this case, commands are collected from amongst all global variables -- cgit v1.2.3-1-g7c22