Parsing console arguments

[robertbasic]

Hi, it's me again! :D sorry for spamming :)

Again, it's about the cli stuff, parsing of the arguments, to be precise.

Right now we have Zend\Console\Getopt for argument parsing. It supports
"named" arguments by using flags, like:

prompt> script.php --foo bar

where we would end up with a parameter foo with value bar.

It also support "notnamed" arguments, like:

prompt> script.php spam ham

Where the [0] argument has the value spam, and the [1] argument has the
value ham.

This all can be mixed, like:

prompt> script.php spam --foo bar

Now, let's say, for example, we have a cli module/controller/action, and we
want to use 2 arguments in that action. If we go with the "named" arguments,
we'd call the action like:

prompt> script.php module controller action --foo spam -b ham

and we could "fetch" these arguments in the controller/action by simply
calling something like:

$this->_request->getParam('foo');

and it wouldn't really matter in what order are the parameters passed, as
they are named + the controller/action gets that much easier to be used in a
HTTP environment. On the other hand, the console call itself gets a bit ugly
with all those dashes and double dashes.

If we go with the "unnamed" arguments, the console call is pretty:

prompt> script.php module controller action spam ham

but the order of the parameters *is* important now, because in the
controller/action we can only do:

$this->_request->getParam(0);

and this can turn out to be a nightmare quite quickly.

Third, and probably this will be the winner, to use the "unnamed" arguments,
but also to have some sort of a Config or some such which would map argument
position to the argument name. This might be even done in Getopt. The order
of the arguments would still matter in this case, but in the
controller/action we could use the getParam('foo') way.

Of course, these arguments would be in a "container"
(Zend\Console\Arguments?) implementing Zend\Stdlib\ParametersDescription so
you actually wouldn't notice they're not from $_GET/$_POST :)

Thoughts?

Happy hackin'!

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

[robertbasic]

Gah! Sorry Matt, didn't hit reply all.

On Mon, Oct 24, 2011 at 11:02 PM, Matt Cockayne <[hidden email]> wrote:

> option 3 gets my +1.
>
> would be good to be able to pass a config and have getopt determine the
> "module", "controller" & "action" or whatever pattern is required for
> routing.
>

Which means we'll end up with a CliRouter of some sort :)


>
> A container class is a good idea
>
> --
~Robert Basic;
http://robertbasic.com/

[mattcockayne]

so...

had a play around with getopt

https://github.com/zucchi/zf2-1/blob/prototype/cli/library/Zend/Console/Getopt.php

now handling arguments by position

*$options = array(*
*    'help|h' => 'HELP',*
*    'verbose|v' => 'VERBOSE',*
*    'action?0' => 'the action or method to run',*
*    'module?1' => 'the module to route to',*
*);*
*$getoptParser = new \Zend\Console\Getopt($options);*
*$getoptParser->parse();*
*
*
*echo $getoptParser->getUsageMessage();*
*$getoptParser->getOption('module')*


The above shows how to map arguments by position using a "?" delimiter with
the key to map it to infront and the position it will read from after.

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

> Gah! Sorry Matt, didn't hit reply all.
>
> On Mon, Oct 24, 2011 at 11:02 PM, Matt Cockayne <[hidden email]> wrote:
>
>> option 3 gets my +1.
>>
>> would be good to be able to pass a config and have getopt determine the
>> "module", "controller" & "action" or whatever pattern is required for
>> routing.
>>
>
> Which means we'll end up with a CliRouter of some sort :)
>
>
>>
>> A container class is a good idea
>>
>> --
> ~Robert Basic;
> http://robertbasic.com/
>

[mattcockayne]

some more fiddling has lead me to an Arguments container that works with
getopt

https://github.com/zucchi/zf2-1/blob/prototype/cli/library/Zend/Console/Arguments.php

takes the options for getopt in the constructor and parses it all out to a
"request" style for passing to controllers...

have kept the opts for getopt limited to action & module to match the
pattern i have in place for my Cli.php setup for now.

[robertbasic]

On Tue, Oct 25, 2011 at 1:57 AM, Matt Cockayne <[hidden email]> wrote:

> some more fiddling has lead me to an Arguments container that works with
> getopt
>
>
> https://github.com/zucchi/zf2-1/blob/prototype/cli/library/Zend/Console/Arguments.php
>
> takes the options for getopt in the constructor and parses it all out to a
> "request" style for passing to controllers...
>
> have kept the opts for getopt limited to action & module to match the
> pattern i have in place for my Cli.php setup for now.
>
>
>

This looks more like a CliRequest, not Arguments.

I have thought about the Arguments to implement
Zend\Stdlib\ParametersDescription and basically to "assemble"/hold all the
arguments parsed with Getopt. Then we can pass this Arguments to the
CliRequest and later on have calls like $this->_request->getParam('foo')

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

[mattcockayne]

my turn to forget to hit reply all

On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]> wrote:

> fair comment.
>
> Yes it is more of a Cli request object... in the rather small hours of this
> morning it seemed like a sensible implementation as it made sense to utilise
> the same functionality as the current http request object to allow it to be
> passed into controllers and provide a similar pattern of usage .to
>
> The one i created is a straight copy of the current http request object
> witha couple of tweaks so only 5 mins of work so no harm done
>
> I can see that it may be more prudent to just use a
> \Zend\Stdlib\ParametersDescription object which we could pass into a request
> object later on. I'll refactor slightly.
>
> something to consider is that as far as i can see there is no getParam()
> method any more in the request objects passed to controllers. It may be
> worth someone revisiting http to make include it if we are definately
> wanting to have that as a convenience function.
>
>
>
> On Tue, Oct 25, 2011 at 6:38 AM, Robert Basic <[hidden email]>wrote:
>>
>>
>> This looks more like a CliRequest, not Arguments.
>>
>> I have thought about the Arguments to implement
>> Zend\Stdlib\ParametersDescription and basically to "assemble"/hold all the
>> arguments parsed with Getopt. Then we can pass this Arguments to the
>> CliRequest and later on have calls like $this->_request->getParam('foo')
>>
>>
>> --
>> ~Robert Basic;
>> http://robertbasic.com/
>>
>
>

[mattcockayne]

K...

that makes a lot more sense now

Arguments is refactored... next time in giong to bed earlier



On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]> wrote:

> my turn to forget to hit reply all
>
>
> On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]> wrote:
>
>> fair comment.
>>
>> Yes it is more of a Cli request object... in the rather small hours of
>> this morning it seemed like a sensible implementation as it made sense to
>> utilise the same functionality as the current http request object to allow
>> it to be passed into controllers and provide a similar pattern of usage .to
>>
>> The one i created is a straight copy of the current http request object
>> witha couple of tweaks so only 5 mins of work so no harm done
>>
>> I can see that it may be more prudent to just use a
>> \Zend\Stdlib\ParametersDescription object which we could pass into a request
>> object later on. I'll refactor slightly.
>>
>> something to consider is that as far as i can see there is no getParam()
>> method any more in the request objects passed to controllers. It may be
>> worth someone revisiting http to make include it if we are definately
>> wanting to have that as a convenience function.
>>
>>
>>
>> On Tue, Oct 25, 2011 at 6:38 AM, Robert Basic <[hidden email]>wrote:
>>>
>>>
>>> This looks more like a CliRequest, not Arguments.
>>>
>>> I have thought about the Arguments to implement
>>> Zend\Stdlib\ParametersDescription and basically to "assemble"/hold all the
>>> arguments parsed with Getopt. Then we can pass this Arguments to the
>>> CliRequest and later on have calls like $this->_request->getParam('foo')
>>>
>>>
>>> --
>>> ~Robert Basic;
>>> http://robertbasic.com/
>>>
>>
>>
>

[robertbasic]

Just forwarding to the list :)

---------- Forwarded message ----------
From: Matt Cockayne <[hidden email]>
Date: Tue, Oct 25, 2011 at 10:08 AM
Subject: Re: [zf-contributors] Parsing console arguments

So... more tweaking

have refactored getopt to parse all args separaely

this now works rather well

*$options = array(*
*    'help|h' => 'HELP',*
*    'verbose|v' => 'VERBOSE',*
*    'action?0' => 'the action or function to run',*
*    'module?1' => 'the module to route to',*
*);*
*$getopt = new Zend\Console\Getopt($options);*
*
*
*Zend\Debug::dump( $getopt->getOptions() );*
*Zend\Debug::dump( $getopt->getNamedArgs() );*
*Zend\Debug::dump( $getopt->getRemainingArgs() );*

prompt> zf2 monkey puzzle tree --v

the three methods getOptions, getNamedArgs, getRemainingArgs now return the
Zend\Console\Arguments object rather than an array

Am contemplating if "GetOpt" is a valid name for the class now???? thoughts

Matt

On Tue, Oct 25, 2011 at 8:00 AM, Matt Cockayne <[hidden email]> wrote:

> Hi
>
> So im thinking that we at least have enough primitives in the Zend\Console
> to work with... I have added you as a collaborator so you can work with the
> junk i have thrown together on my repo.
>
> feel free to hack away
>
> Matt
>
>
> On Tue, Oct 25, 2011 at 7:14 AM, Matt Cockayne <[hidden email]> wrote:
>
>> K...
>>
>> that makes a lot more sense now
>>
>> Arguments is refactored... next time in giong to bed earlier
>>
>>
>>
>> On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]> wrote:
>>
>>> my turn to forget to hit reply all
>>>
>>>
>>> On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]>wrote:
>>>
>>>> fair comment.
>>>>
>>>> Yes it is more of a Cli request object... in the rather small hours of
>>>> this morning it seemed like a sensible implementation as it made sense to
>>>> utilise the same functionality as the current http request object to allow
>>>> it to be passed into controllers and provide a similar pattern of usage .to
>>>>
>>>> The one i created is a straight copy of the current http request object
>>>> witha couple of tweaks so only 5 mins of work so no harm done
>>>>
>>>> I can see that it may be more prudent to just use a
>>>> \Zend\Stdlib\ParametersDescription object which we could pass into a request
>>>> object later on. I'll refactor slightly.
>>>>
>>>> something to consider is that as far as i can see there is no getParam()
>>>> method any more in the request objects passed to controllers. It may be
>>>> worth someone revisiting http to make include it if we are definately
>>>> wanting to have that as a convenience function.
>>>>
>>>>
>>>>
>>>> On Tue, Oct 25, 2011 at 6:38 AM, Robert Basic <
>>>> [hidden email]> wrote:
>>>>>
>>>>>
>>>>> This looks more like a CliRequest, not Arguments.
>>>>>
>>>>> I have thought about the Arguments to implement
>>>>> Zend\Stdlib\ParametersDescription and basically to "assemble"/hold all the
>>>>> arguments parsed with Getopt. Then we can pass this Arguments to the
>>>>> CliRequest and later on have calls like $this->_request->getParam('foo')
>>>>>
>>>>>
>>>>
>>>
>>

[mattcockayne]

i really need to find a way to set the default in gmail to reply all :D

On Tue, Oct 25, 2011 at 9:15 AM, Robert Basic <[hidden email]>wrote:

> Just forwarding to the list :)
>
> ---------- Forwarded message ----------
> From: Matt Cockayne <[hidden email]>
> Date: Tue, Oct 25, 2011 at 10:08 AM
> Subject: Re: [zf-contributors] Parsing console arguments
>
> So... more tweaking
>
> have refactored getopt to parse all args separaely
>
> this now works rather well
>
> *$options = array(*
> *    'help|h' => 'HELP',*
> *    'verbose|v' => 'VERBOSE',*
> *    'action?0' => 'the action or function to run',*
> *    'module?1' => 'the module to route to',*
> *);*
> *$getopt = new Zend\Console\Getopt($options);*
> *
> *
> *Zend\Debug::dump( $getopt->getOptions() );*
> *Zend\Debug::dump( $getopt->getNamedArgs() );*
> *Zend\Debug::dump( $getopt->getRemainingArgs() );*
>
> prompt> zf2 monkey puzzle tree --v
>
> the three methods getOptions, getNamedArgs, getRemainingArgs now return the
> Zend\Console\Arguments object rather than an array
>
> Am contemplating if "GetOpt" is a valid name for the class now???? thoughts
>
> Matt
>
> On Tue, Oct 25, 2011 at 8:00 AM, Matt Cockayne <[hidden email]> wrote:
>
> > Hi
> >
> > So im thinking that we at least have enough primitives in the
> Zend\Console
> > to work with... I have added you as a collaborator so you can work with
> the
> > junk i have thrown together on my repo.
> >
> > feel free to hack away
> >
> > Matt
> >
> >
> > On Tue, Oct 25, 2011 at 7:14 AM, Matt Cockayne <[hidden email]>
> wrote:
> >
> >> K...
> >>
> >> that makes a lot more sense now
> >>
> >> Arguments is refactored... next time in giong to bed earlier
> >>
> >>
> >>
> >> On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]>
> wrote:
> >>
> >>> my turn to forget to hit reply all
> >>>
> >>>
> >>> On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]
> >wrote:
> >>>
> >>>> fair comment.
> >>>>
> >>>> Yes it is more of a Cli request object... in the rather small hours of
> >>>> this morning it seemed like a sensible implementation as it made sense
> to
> >>>> utilise the same functionality as the current http request object to
> allow
> >>>> it to be passed into controllers and provide a similar pattern of
> usage .to
> >>>>
> >>>> The one i created is a straight copy of the current http request
> object
> >>>> witha couple of tweaks so only 5 mins of work so no harm done
> >>>>
> >>>> I can see that it may be more prudent to just use a
> >>>> \Zend\Stdlib\ParametersDescription object which we could pass into a
> request
> >>>> object later on. I'll refactor slightly.
> >>>>
> >>>> something to consider is that as far as i can see there is no
> getParam()
> >>>> method any more in the request objects passed to controllers. It may
> be
> >>>> worth someone revisiting http to make include it if we are definately
> >>>> wanting to have that as a convenience function.
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Oct 25, 2011 at 6:38 AM, Robert Basic <
> >>>> [hidden email]> wrote:
> >>>>>
> >>>>>
> >>>>> This looks more like a CliRequest, not Arguments.
> >>>>>
> >>>>> I have thought about the Arguments to implement
> >>>>> Zend\Stdlib\ParametersDescription and basically to "assemble"/hold
> all the
> >>>>> arguments parsed with Getopt. Then we can pass this Arguments to the
> >>>>> CliRequest and later on have calls like
> $this->_request->getParam('foo')
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>

[Thomas DUTRION]

Hi mattcockayne,

There is a way to set default to reply all in Gmail :

• click on the top right corner
• click on labs
• search "Reply to all" in experimental functionnalities

I'm sorry, my Gmail is in french, so I'm not sure the names are right.

2011/10/25 mattcockayne [via Zend Framework Community] <[hidden email]>

i really need to find a way to set the default in gmail to reply all :D

On Tue, Oct 25, 2011 at 9:15 AM, Robert Basic <[hidden email]>wrote:

> Just forwarding to the list :)
>
> ---------- Forwarded message ----------
> From: Matt Cockayne <[hidden email]>
> Date: Tue, Oct 25, 2011 at 10:08 AM
> Subject: Re: [zf-contributors] Parsing console arguments
>
> So... more tweaking
>
> have refactored getopt to parse all args separaely
>
> this now works rather well
>
> *$options = array(*
> *    'help|h' => 'HELP',*
> *    'verbose|v' => 'VERBOSE',*
> *    'action?0' => 'the action or function to run',*
> *    'module?1' => 'the module to route to',*
> *);*
> *$getopt = new Zend\Console\Getopt($options);*
> *
> *
> *Zend\Debug::dump( $getopt->getOptions() );*
> *Zend\Debug::dump( $getopt->getNamedArgs() );*
> *Zend\Debug::dump( $getopt->getRemainingArgs() );*
>
> prompt> zf2 monkey puzzle tree --v
>
> the three methods getOptions, getNamedArgs, getRemainingArgs now return the
> Zend\Console\Arguments object rather than an array
>
> Am contemplating if "GetOpt" is a valid name for the class now???? thoughts
>
> Matt
>
> On Tue, Oct 25, 2011 at 8:00 AM, Matt Cockayne <[hidden email]> wrote:
>
> > Hi
> >
> > So im thinking that we at least have enough primitives in the
> Zend\Console
> > to work with... I have added you as a collaborator so you can work with
> the
> > junk i have thrown together on my repo.
> >
> > feel free to hack away
> >
> > Matt
> >
> >
> > On Tue, Oct 25, 2011 at 7:14 AM, Matt Cockayne <[hidden email]>
> wrote:
> >
> >> K...
> >>
> >> that makes a lot more sense now
> >>
> >> Arguments is refactored... next time in giong to bed earlier
> >>
> >>
> >>
> >> On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]>
> wrote:
> >>
> >>> my turn to forget to hit reply all
> >>>
> >>>
> >>> On Tue, Oct 25, 2011 at 7:03 AM, Matt Cockayne <[hidden email]
> >wrote:
> >>>
> >>>> fair comment.
> >>>>
> >>>> Yes it is more of a Cli request object... in the rather small hours of
> >>>> this morning it seemed like a sensible implementation as it made sense
> to
> >>>> utilise the same functionality as the current http request object to
> allow
> >>>> it to be passed into controllers and provide a similar pattern of
> usage .to
> >>>>
> >>>> The one i created is a straight copy of the current http request
> object
> >>>> witha couple of tweaks so only 5 mins of work so no harm done
> >>>>
> >>>> I can see that it may be more prudent to just use a
> >>>> \Zend\Stdlib\ParametersDescription object which we could pass into a
> request
> >>>> object later on. I'll refactor slightly.
> >>>>
> >>>> something to consider is that as far as i can see there is no
> getParam()
> >>>> method any more in the request objects passed to controllers. It may
> be
> >>>> worth someone revisiting http to make include it if we are definately
> >>>> wanting to have that as a convenience function.
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Oct 25, 2011 at 6:38 AM, Robert Basic <
> >>>> [hidden email]> wrote:
> >>>>>
> >>>>>
> >>>>> This looks more like a CliRequest, not Arguments.
> >>>>>
> >>>>> I have thought about the Arguments to implement
> >>>>> Zend\Stdlib\ParametersDescription and basically to "assemble"/hold
> all the
> >>>>> arguments parsed with Getopt. Then we can pass this Arguments to the
> >>>>> CliRequest and later on have calls like
> $this->_request->getParam('foo')
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/Parsing-console-arguments-tp3934526p3935994.html

To unsubscribe from Zend Framework Community, click here.