commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Oxspring <roxspr...@imapmail.org>
Subject Re: [CLI] 2.x Tasks
Date Sun, 02 Nov 2003 00:55:27 GMT
John Keyes wrote:

> Our current group support is limited to mutually
> exclusive groups.  We need to support inclusive
> groups also.  This will allow more than one option
> to have the same child options.  Let me know if you
> have any thoughts on it.

There's currently no problem with assigning the same group as children 
to more than one parent but I'm not 100% sure this is tackling the same 
problem.  Any chance of a toy example of inclusive groups to make sure 
we're on the same wavelength?

Cheers,

Rob

>
> -John K
>
> On 1 Nov 2003, at 14:43, John Keyes wrote:
>
>>>>    . mandatory groups
>>>
>>> I think this can be achieved using min/max with Groups but I might 
>>> be missing the point.  I'm not going to claim that this is well 
>>> documented or intuitive though so ideas welcome.
>>
>> Doh!  Of course.
>>
>>>>    . child Options
>>>
>>> Parent instances can have a "children" Group - doesn't this take 
>>> care of things?  Or do you want to have a single child?
>>
>> I forgot Group extends Options.
>>
>>> I'm quite happy to add the tasks but my head needs a bit more detail 
>>> to get round it at the moment.
>>
>> No need, I've got my head around them now.
>>
>>> As for other tasks...
>>>
>>> I've got code in the wings for a SourceDestArgument.  It was meant as a
>>> worked example of extending the system but I'm wondering whether it 
>>> might
>>> just as well be included.  Basically it implements the logic of "cp"s
>>> arguments - many sources + 1 destination, allowing the user to get 
>>> around
>>> the greedy parsing logic.  Thoughts? More code/explanation needed?
>>
>> Nice idea.  It will be important to have good documentation to show
>> how many of the new features in 2.x works.  This sounds like a good
>> example, we can include it in the distribution and also document it
>> as an extension example.  Whether this should be considered a core
>> feature or an extension feature is another question?  If we have
>> other extension examples maybe we should put this into a separate
>> package?
>>
>>> I've also got work in progress code to allow defaults to be taken from
>>> another CommandLine instance.  The idea is that these can be daisy 
>>> chained
>>> and then other parsers can be written to deal with Properties, 
>>> Prefs, xml?,
>>> CommonsConfiguration?? etc.  Along with the parser logic, writing logic
>>> could be added to arrive at property setting logic requested in one 
>>> of the
>>> bugs.  Does this sound like goodness?  I'll go into detail about the
>>> thoughts re parsing and writing as I'm struggling to find the right 
>>> api in
>>> my head.
>>
>>
>> I'd like to see the code for this.  I was going to start work on the
>> properties/prefs/... task next.
>>
>>> And while I'm here and awake (almost) - I added getId() to Option 
>>> the other
>>> day so that switching can be performed on options but the code makes no
>>> attempt to ensure the id's don't clash or to automatically assign 
>>> ids.  I
>>> briefly had it using the (char) of any 1 character shortNames or an 
>>> ever
>>> increasing number otherwise but that just seemed to be trying too 
>>> hard and
>>> achieving too little and I figured I'd chuck responsibility to the 
>>> user that
>>> wants to use ids.  Which is this the right approach?
>>
>>
>> Yeah I saw this.  I think it is the correct approach.  Originally this
>> requirement came from some code in Avalon, this was a specific case 
>> where
>> each option was only one character.  This should be easy to wrap for the
>> cli package delegators as well.
>>
>> Now that we have jira on nagoya should we move to use this instead of
>> Bugzilla?  No biggy, but it is much a nicer interface than bugzilla.
>>
>> -John K
>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message