You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2007/08/14 16:09:09 UTC

[CLI] CLI Validation - Was: WELCOME to dev@commons.apache.org

Hi Wolfgang,

It's great that the bugfix release has driven some interest onto the
lists for improving the library. Validation sounds very useful - is it
something that you think Commons Validator would be useful for, or do
the use cases not quite match?

Brian and others... any thoughts?

CLI future wise, I think we're looking at:

* CLI 1.2. Consider whether a bugfix release is required. Make small
changes, nothing too huge.

* CLI2. Need to get the 17 2.0 issues taken care of and look to
releasing CLI 2.0 [or CLI2 1.0]. There seems to be enough interest in
CLI2 for us to move to this.

Hen

On 8/14/07, Wolfgang Roessler <co...@roessler-wolfgang.de> wrote:
> Hi,
>
> switching from the user to the developer-list, I just post the same mail again *g.
>
> I came across CLI some time ago, when I was looking for a "framework" to help me process the command-line easily. I tried CLI1.1 and CLI2 and I have to admit, I am satisfied with neither.
>
> While parsing works as far as I have tried, the validation (which I consider more important and costly) is not yet what I expect. While CLI1.1 offers nothing, CLI2 at least has some simple checks. I would need a flexible approach for modelling (complex) dependencies.
>
> What I would expect is, that I only have to specify the command-line (available options, dependencies, special validations ...) and all parsing and validation is done for me.
>
> I don't only want to complain about the situation, but I want to offer my help. If there is a clear direction where to go, I am willing to invest some time to help with a new release. The idee of CLI is great, but for a really useful solution in my opinion a lot has to be improved.
>
> Greets
> Wolfgang
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Re: [CLI] CLI Validation - Was: WELCOME to dev@commons.apache.org

Posted by Oliver Heger <ol...@oliver-heger.de>.
Brian A. Egge wrote:
> Hi Wolfgang,
> 
> I agree that the framework should have better support for groups and mutually exclusive options.  This is a feature I've often had to do in a pre or post processing step.  
> 
> I've thought about writing a CLI library which would accept a EBNF option grammar, much like JavaCC or ANTLR.  You could do the validation, and assign actions to options or commands.  A simple grammar would be easier to specify the arguments than a *Builder object.  Realistically, though, I know I don't have the time to take on such a project, so my best bet it to improve on one of the existing projects.
> 
> I should have some time in the next few weeks to get some fixes into CLI 2.x, and look at ways of making it do smarter validation.
> 
> -Brian

A grammer is certainly a precise and compact way of defining the allowed
command line arguments, but in can also become quite complex. I assume
the average user of a CLI library is not used to thinking this way.

How about defining a set of extensible rules, which describe the
supported arguments? There could be default rules like
- parameter foo must have one of these values (a, b, c)
- if parameter foo is present, bar must not be present
- an existing file must be specified
...

If the default rules are not enough for defining a complex parameter
interface, custom rules could be defined. The rules could be either
defined using a builder-like approach or read from some kind of
definition file.

This sounds a bit like Digester, doesn't it? And indeed using such a
library could look as follows:
- An application object is passed to CLI.
- CLI processes the command line arguments based on the specified rules.
- Setter methods on the application object are invoked with the
identified command line options.

This would be easy and convenient to use, but if the interface of the
rules is carefully designed, very flexible.

My $0.02
Oliver

> 
> Wolfgang Roessler <co...@roessler-wolfgang.de> wrote: Hi Hen,
> 
> the Commons Validator package sounds interesting and I perhaps it should 
> be possible to use these validators. But I also like the CLI2 validators 
> for files and directories. The validators I am missing are something 
> like dependency-validators, e.g. specify mutually exclusive options. 
> Groups offer very little support for this.
> 
> Currently validation and parsing is mixed up I think. This way if I pass 
> a filename and the file should be writable but it isn't, I get an error 
> that the option is missing and not, that there is a problem with the 
> specified file. Perhaps this should be separated in a FileOption and the 
> validator.
> 
> In my opinion the target of CLI2 should be, that all parsing and 
> validation is performed by the framework.
> 
> Wolfgang
> 
> 


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


Re: [CLI] CLI Validation - Was: WELCOME to dev@commons.apache.org

Posted by "Brian A. Egge" <br...@yahoo.com>.
Hi Wolfgang,

I agree that the framework should have better support for groups and mutually exclusive options.  This is a feature I've often had to do in a pre or post processing step.  

I've thought about writing a CLI library which would accept a EBNF option grammar, much like JavaCC or ANTLR.  You could do the validation, and assign actions to options or commands.  A simple grammar would be easier to specify the arguments than a *Builder object.  Realistically, though, I know I don't have the time to take on such a project, so my best bet it to improve on one of the existing projects.

I should have some time in the next few weeks to get some fixes into CLI 2.x, and look at ways of making it do smarter validation.

-Brian

Wolfgang Roessler <co...@roessler-wolfgang.de> wrote: Hi Hen,

the Commons Validator package sounds interesting and I perhaps it should 
be possible to use these validators. But I also like the CLI2 validators 
for files and directories. The validators I am missing are something 
like dependency-validators, e.g. specify mutually exclusive options. 
Groups offer very little support for this.

Currently validation and parsing is mixed up I think. This way if I pass 
a filename and the file should be writable but it isn't, I get an error 
that the option is missing and not, that there is a problem with the 
specified file. Perhaps this should be separated in a FileOption and the 
validator.

In my opinion the target of CLI2 should be, that all parsing and 
validation is performed by the framework.

Wolfgang


Re: [CLI] CLI Validation - Was: WELCOME to dev@commons.apache.org

Posted by Wolfgang Roessler <co...@roessler-wolfgang.de>.
Hi Hen,

the Commons Validator package sounds interesting and I perhaps it should 
be possible to use these validators. But I also like the CLI2 validators 
for files and directories. The validators I am missing are something 
like dependency-validators, e.g. specify mutually exclusive options. 
Groups offer very little support for this.

Currently validation and parsing is mixed up I think. This way if I pass 
a filename and the file should be writable but it isn't, I get an error 
that the option is missing and not, that there is a problem with the 
specified file. Perhaps this should be separated in a FileOption and the 
validator.

In my opinion the target of CLI2 should be, that all parsing and 
validation is performed by the framework.

Wolfgang
> Hi Wolfgang,
>
> It's great that the bugfix release has driven some interest onto the
> lists for improving the library. Validation sounds very useful - is it
> something that you think Commons Validator would be useful for, or do
> the use cases not quite match?
>
> Brian and others... any thoughts?
>
> CLI future wise, I think we're looking at:
>
> * CLI 1.2. Consider whether a bugfix release is required. Make small
> changes, nothing too huge.
>
> * CLI2. Need to get the 17 2.0 issues taken care of and look to
> releasing CLI 2.0 [or CLI2 1.0]. There seems to be enough interest in
> CLI2 for us to move to this.
>
> Hen
>
> On 8/14/07, Wolfgang Roessler <co...@roessler-wolfgang.de> wrote:
>   
>> Hi,
>>
>> switching from the user to the developer-list, I just post the same mail again *g.
>>
>> I came across CLI some time ago, when I was looking for a "framework" to help me process the command-line easily. I tried CLI1.1 and CLI2 and I have to admit, I am satisfied with neither.
>>
>> While parsing works as far as I have tried, the validation (which I consider more important and costly) is not yet what I expect. While CLI1.1 offers nothing, CLI2 at least has some simple checks. I would need a flexible approach for modelling (complex) dependencies.
>>
>> What I would expect is, that I only have to specify the command-line (available options, dependencies, special validations ...) and all parsing and validation is done for me.
>>
>> I don't only want to complain about the situation, but I want to offer my help. If there is a clear direction where to go, I am willing to invest some time to help with a new release. The idee of CLI is great, but for a really useful solution in my opinion a lot has to be improved.
>>
>> Greets
>> Wolfgang
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>   


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