On 25 August 2010 03:42, Moacir de Oliveira <moacirdeoliveira....@gmail.com> wrote: > Hi Daniel, > > 2010/8/24 Daniel Convissor <dani...@analysisandsolutions.com> >> >> Hi Moacir: >> >> On Sat, Aug 21, 2010 at 02:24:40AM -0400, Moacir de Oliveira wrote: >> >> > Some options in PhD are specific for rendering the PHP Manual (--notoc, >> > --lang). These options make no effect if used with the other packages, >> > so >> > would be interesting extract them from the core of PhD and implement >> > these >> > options within the PHP package. >> > >> > Syntax: >> > $ phd --<package>-<option> <value> >> >> Having generic options and package options is cool. Naming the options >> for the package feels a bit clunky. Some options may not be used in >> another package now, but could in the future, so it will lead to lots of >> duplication (--php-foo --pear-foo --etc-foo) and extra typing. > > The idea is to use the package options just for really specific options. I > think that options that could be used for more than one package should be > written as a core option. > I agree that typing --php-foo --pear-foo --etc-foo... is painful but I'm not > sure if is already possible to render more than one package at once, I think > it only works for formats that exist in all packages passed. > > The old options were not changed (so $ phd -d .manual.xml -f xhtml -P PHP > stills working fine) > >> >> Perhaps leave the option named --foo, but have it only available inside >> the packages that use it? When used for a package that doesn't utilize >> that option, a warning could be issued. >> > > The syntax --<package>-<option> is to prevent duplication, it makes all > options unique for PhD. Using just --foo is also a possibility, but I think > it's not so clear for the user to know which package will handle it. > > let's discuss it > > > --Moacir de Oliveira > >
The PEAR approach for this (via the Console_CommandLine package [1]) is to have "commands" So something like ... script.php --generic-option command --command-option sub-command --sub-command-option can be fully realized. When building the command line rules, a subcommand and command specific options can be attached to any command. For example, the -h/--help option exists for all commands/subcommands. script.php --help script.php command --help script.php command subcommand --help each will give appropriate help for the level being used (generic, command and then subcommand). Sub-commands and command-options can be used across any number of "commands" and to any depth. Obviously, a "package" isn't necessarily a "command" and PhD doesn't use PEAR (except for CS). But that's how PEAR handles this. -- Richard Quadling. [1] http://pear.php.net/package/Console_CommandLine
