Improving Zend\Console

[robertbasic]

Hi all!

While working on the cli module, I have a few ideas of (hopefully) improving
the Zend\Console component.

First, Zend\Console\Getopt (these are basically implementations of those
couple of @todo's in the code itself).

 - Currently, Getopt's getUsage only prints out how to use it based on the
registered arguments. Add the possibility of adding a header/footer content,
or maybe short description/long description. Use case: so that one can
generate an output something like "prompt> ls --help" would generate. Big
nice message + usage.

 - Obviously, implement a --help argument which would call Getopt::help,
which in turn calls getUsage + short/long description.

Second, introduce a Zend\Console\Output component, which would, probably,
implement Zend\Stdlib\MessageDescription. If makes sense, get out as much as
possible from Zend\Tool\Client\Response.

Also, move Zend\Tool\Client\Console\ResponseDecorator to
Zend\Console\Output\Decorator and make it use the Zend\Loader\Broker|Loader
stuff. All decorators should implement a Decorator interface. If makes
sense, add a "DecoratorAggregator" class which can aggregate output
decorators and all these decorators can be applied to the Output. Order of
applying shouldn't make a difference.

Thoughts? Anything I missed?

Happy hackin'!

--
~Robert Basic;
http://robertbasic.com/

[mattcockayne]

+1 for refactoring getopt.

would be good to have a way to map non hyphenated arguments properly based
upon numeric index with anything that is not mapped being carried over as a
remaining arg.

would be good for getopt to follow the common -Dkey=value pattern also for
key value params

+1 for an Output object... however would like to see it much simpler than
the current tool implementation

would like to see a Zend\Console\Environment for determining the current
console environment



On Mon, Oct 24, 2011 at 8:37 PM, Robert Basic <[hidden email]>wrote:

> Hi all!
>
> While working on the cli module, I have a few ideas of (hopefully)
> improving
> the Zend\Console component.
>
> First, Zend\Console\Getopt (these are basically implementations of those
> couple of @todo's in the code itself).
>
>  - Currently, Getopt's getUsage only prints out how to use it based on the
> registered arguments. Add the possibility of adding a header/footer
> content,
> or maybe short description/long description. Use case: so that one can
> generate an output something like "prompt> ls --help" would generate. Big
> nice message + usage.
>
>  - Obviously, implement a --help argument which would call Getopt::help,
> which in turn calls getUsage + short/long description.
>
> Second, introduce a Zend\Console\Output component, which would, probably,
> implement Zend\Stdlib\MessageDescription. If makes sense, get out as much
> as
> possible from Zend\Tool\Client\Response.
>
> Also, move Zend\Tool\Client\Console\ResponseDecorator to
> Zend\Console\Output\Decorator and make it use the Zend\Loader\Broker|Loader
> stuff. All decorators should implement a Decorator interface. If makes
> sense, add a "DecoratorAggregator" class which can aggregate output
> decorators and all these decorators can be applied to the Output. Order of
> applying shouldn't make a difference.
>
> Thoughts? Anything I missed?
>
> Happy hackin'!
>
> --
> ~Robert Basic;
> http://robertbasic.com/
>

[DeNix]

+ 1 for refactoring

I myself use getopt a lot, and was about to propose refactoring of
Zend\Console wich includes


- named options and more decriptive configuration for an option
   so one could set option like this

   $opt->setOption('foo', array(
         'short_name'  => 'f',
         'long_name'   => array('foo', 'fooo'), // aliases
         'required'    => true,
         'default'     => 'bar',
         'description' => 'This option does foo' // for usage message
   ));

   and later get it as

$opt->getOption('foo') // but not $opt->getOption('f')

- named arguments
   so one could do
   $opt->setArguments(array(
       0 => 'controller',
       1 => 'action',
       2 => 'param'.
   ));

   so then command line like this
 > script.php foo bar new -v 5

   with
   $args = $opt->getArguments();

   should give you $args as
   array(
     'controller' => 'foo',
     'action' => 'bar',
     'param' => 'new'
   )

- parse short options without spaces so '-f5' equals '-f 5'

- ability to turn off exceptions
   so one could get an array of parsed options no matter valid or not
   and send it to Zend\Filter\InputFilter for filtering/validation

- ability to add header/footer to usage message


On 24.10.2011 23:37, Robert Basic wrote:

> Hi all!
>
> While working on the cli module, I have a few ideas of (hopefully) improving
> the Zend\Console component.
>
> First, Zend\Console\Getopt (these are basically implementations of those
> couple of @todo's in the code itself).
>
>   - Currently, Getopt's getUsage only prints out how to use it based on the
> registered arguments. Add the possibility of adding a header/footer content,
> or maybe short description/long description. Use case: so that one can
> generate an output something like "prompt>  ls --help" would generate. Big
> nice message + usage.
>
>   - Obviously, implement a --help argument which would call Getopt::help,
> which in turn calls getUsage + short/long description.
>
> Second, introduce a Zend\Console\Output component, which would, probably,
> implement Zend\Stdlib\MessageDescription. If makes sense, get out as much as
> possible from Zend\Tool\Client\Response.
>
> Also, move Zend\Tool\Client\Console\ResponseDecorator to
> Zend\Console\Output\Decorator and make it use the Zend\Loader\Broker|Loader
> stuff. All decorators should implement a Decorator interface. If makes
> sense, add a "DecoratorAggregator" class which can aggregate output
> decorators and all these decorators can be applied to the Output. Order of
> applying shouldn't make a difference.
>
> Thoughts? Anything I missed?
>
> Happy hackin'!
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Ralph Schindler-2]

>   - Currently, Getopt's getUsage only prints out how to use it based on the
> registered arguments. Add the possibility of adding a header/footer content,
> or maybe short description/long description. Use case: so that one can
> generate an output something like "prompt>  ls --help" would generate. Big
> nice message + usage.

originally, (i think), Zend\Console\Getopt was attempting to be as
equivilant to unix getopt() as possible while adding additional
functionality.

I am not sure I see my value in supporting php's getopt() or the unix
getopt() formats.  I'd rather see a more flexible (configurable) parser
for the stuff we find in the $_SERVER['argv'] array.  That makes the
most sense to me, and it would reduce the Zend\Console\Getopt codebase.

I had to hack it around to make it so that I could chain getopt
configurations since it did not understand word stops out of the box.
(This was for the Zend_Tool work).

>   - Obviously, implement a --help argument which would call Getopt::help,
> which in turn calls getUsage + short/long description.

I think we need to find the mimimal set of information associated with a
command and create an interface for it.  Cli should be as easy as:

  $console->addCommand(new MyCommand);

> Second, introduce a Zend\Console\Output component, which would, probably,
> implement Zend\Stdlib\MessageDescription. If makes sense, get out as much as
> possible from Zend\Tool\Client\Response.

The original design of Zend_Tool was to support more than console, this
is why it's simply called a client.  The output of the command being run
could be xml or json, and be used (for example) under the hood with an
IDE or pluggable text editor.

If that is no longer a goal, it can be factored out. Otherwise, I still
think we need a bit of an abstraction layer so Zend_Tool can switch
dependening on the environment it was called in.

> Also, move Zend\Tool\Client\Console\ResponseDecorator to
> Zend\Console\Output\Decorator and make it use the Zend\Loader\Broker|Loader
> stuff. All decorators should implement a Decorator interface. If makes
> sense, add a "DecoratorAggregator" class which can aggregate output
> decorators and all these decorators can be applied to the Output. Order of
> applying shouldn't make a difference.

see above.

> Thoughts? Anything I missed?
>
> Happy hackin'!
>

Great start!

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Ralph Schindler-2]

> + 1 for refactoring

+2 on refactoring :)



> so then command line like this
>  > script.php foo bar new -v 5

Do we group options to a particular argument?  For example, using git,
there is a notion of options that are global (git --options), but also
specific to a group of commands (git remote --help).

Is this something the codebase should support in Zend\Console\GetOpt, or
in the consumer?

> with
> $args = $opt->getArguments();
>
> should give you $args as
> array(
> 'controller' => 'foo',
> 'action' => 'bar',
> 'param' => 'new'
> )
>
> - parse short options without spaces so '-f5' equals '-f 5'
>
> - ability to turn off exceptions
> so one could get an array of parsed options no matter valid or not
> and send it to Zend\Filter\InputFilter for filtering/validation

How much validation are we talking about? Simple validation like "does
this look like a number or a string" or more specific domain validation?

> - ability to add header/footer to usage message

-ralph

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[DeNix]

On 25.10.2011 21:47, Ralph Schindler wrote:

>
>> so then command line like this
>> > script.php foo bar new -v 5
>
> Do we group options to a particular argument?  For example, using git,
> there is a notion of options that are global (git --options), but also
> specific to a group of commands (git remote --help).
>
> Is this something the codebase should support in Zend\Console\GetOpt,
> or in the consumer?

That's a good point

One one hand, if we are talking about future CLI MVC application, GetOpt
shouldn't play significant role here
It's purpose is just to parse $_SERVER['argv'] and provide the result in
some convinient form (CliRequest ? ) to be processed by consumer
Then I guess,  there should be CliRouter to route request to proper
controller
In this case even usage message should be printed by ErrorController

But also, I guess, one should be able to use GetOpt without full blown MVC
so parsed options and arguments should be accessable in form of array

>>
>> - ability to turn off exceptions
>> so one could get an array of parsed options no matter valid or not
>> and send it to Zend\Filter\InputFilter for filtering/validation
>
> How much validation are we talking about? Simple validation like "does
> this look like a number or a string" or more specific domain validation?
>

Considering the above, I think, GetOpt should just check
optional/required and specific validation done by consumer
Btw, It also overcomes current limitation when option parameter can not
be int OR string, so you can't do something like
 > script.php --mem-limit=4096 (int)
 > script.php --mem-limit=1M    (string)

Thanks
Denis


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[drm-4]

Hi guys,

I have not really been following the GetOpt component, but I have
implemented one myself that doesn't work that well (so why bother
mentioning it, right? ;)).

I have tried several approaches, and conclusively the following is my
suggestion, based on my experience. I'm just throwing it in, not sure it
is of any help and if you ignore it I wouldn't be offended, as I haven't
taken the time to dig deeper into the component. :)

Arguments are analogous to XML.

You have input, $_SERVER['argv']  (the source XML)
You'll have a parser and a way to retrieve data from an arbitrary set of
arguments (DOM)
You have a validator, which checks if the arguments are ok (an XSD)
You have a transformer, which applies a set of transformations to the
argument list (XSLT)

The validation an transformation process are independent, so you could
transform before you validate and vice versa. Any option that has
multiple variants (such as '-v' == '--version') has one single
representation in the final set of parameters, so that is part of the
transformation proces.

The main advantage is that you can leave the parsing, validating and
transforming up to the implementation and thus you can have any
implementation you like.

The consumer of the end result should be simply some component that can
transform a set of arguments into a set of named values, e.g.
./script.php a b --env="test" --debug could ultimately map to
array('controller' => 'a', 'action' => 'b', 'debug' => true,
'APPLICATION_ENV' => 'test').

If you have it this way, the end result of the transformation can be a
CliRequest that simply implements the interface that defines the
contract of transforming one list of arguments into another :).

Gerard

On 10/25/2011 09:02 PM, Denis Portnov wrote:

> On 25.10.2011 21:47, Ralph Schindler wrote:
>>
>>> so then command line like this
>>> > script.php foo bar new -v 5
>>
>> Do we group options to a particular argument?  For example, using
>> git, there is a notion of options that are global (git --options),
>> but also specific to a group of commands (git remote --help).
>>
>> Is this something the codebase should support in Zend\Console\GetOpt,
>> or in the consumer?
>
> That's a good point
>
> One one hand, if we are talking about future CLI MVC application,
> GetOpt shouldn't play significant role here
> It's purpose is just to parse $_SERVER['argv'] and provide the result
> in some convinient form (CliRequest ? ) to be processed by consumer
> Then I guess,  there should be CliRouter to route request to proper
> controller
> In this case even usage message should be printed by ErrorController
>
> But also, I guess, one should be able to use GetOpt without full blown
> MVC
> so parsed options and arguments should be accessable in form of array
>
>>>
>>> - ability to turn off exceptions
>>> so one could get an array of parsed options no matter valid or not
>>> and send it to Zend\Filter\InputFilter for filtering/validation
>>
>> How much validation are we talking about? Simple validation like
>> "does this look like a number or a string" or more specific domain
>> validation?
>>
>
> Considering the above, I think, GetOpt should just check
> optional/required and specific validation done by consumer
> Btw, It also overcomes current limitation when option parameter can
> not be int OR string, so you can't do something like
> > script.php --mem-limit=4096 (int)
> > script.php --mem-limit=1M    (string)
>
> Thanks
> Denis
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]