commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <>
Subject Re: [CLI] 2.x Tasks
Date Sun, 02 Nov 2003 21:04:00 GMT
>>>> Here's a toy example:
>>>> -topleft -x 10 -y 10 -bottomright -x 20 -y 20
>>>> where the group is the x and y Arguments.
>>>> Does that make any sense?
>>> Annoyingly, yes. :)
>>> So the problem is that when querying a CommandLine configured by the
>>> above
>>> we have no way of which -x and -y go with which -topleft and
>>> -bottomright.
> This is the problem you're trying to solve right?

>>> The only way to achive this query is to use the path of the options
>>> along
>>> the lines of:
>>>     xValue = commandLine.getValue("-topleft","-x");
>>> I don't see any reason for limiting the path length so I guess the 
>>> api needs
>>> to allow for an array / list / iterator or similar.  Of course this 
>>> means
>>> that the current option->values map is no longer up to the job, and 
>>> some
>>> path->values is going to be needed.  I'm beginning to think that we 
>>> need an
>>> object to represent a option's path to key from.
>> Well my idea was to have an inclusive group.  So we could have:
>> Group coords = gBuilder.withOption(x)
>>                         .withOption(y)
>>                         .withType(Group.INCLUSIVE);
>> Option topleft = oBuilder.withShortName("topleft")
>>                           .withOption(coords)
>>                           .create();
>> Option bottomright = oBuilder.withShortName("bottomright")
>>                               .withOption(coords)
>>                               .create();
>> Then the process logic in GroupImpl will check that all
>> of the options in that group are present, if not throw
>> a MissingOptionException.
>> How does that sound?  This sounds like a much simpler
>> solution rather than the Path proposal.  If I am
>> missing something let me know.
> That should work fine for parsing and validating but there is still the
> problem at the interrogation stage.  When the querying code then does a
> List xValues = cl.getValues(x);
> It'll be faced with the values of both the topleft x and the 
> bottomright x,
> in an order dependant on the command line arguments supplied.  This 
> would
> work but it seems to me that we should do more.
> That make sense?

I knew I was missing something :-)  The Preferences API uses '/' as the
separator and so does XPath so I think we should go with that?  If
max > 1 we should use array notation with indicies beginning at 0?

So we could use:
   getValue("/topleft/x");    // return a List of size 1

If the max = 2 we could use:
   getValue("/topleft/x[1]"); // return a List of size 1
   getValue("/topleft/x");    // return a List of size 2

Should we drop the support for the trigger? So regardless of the
trigger could we retrieve values without it:


internally if the string does not contain any '/' we search for
"/topleft".  This will give us a single means of retrieving the

(more further down)

>>> For this to work we need to arrange for the pathToValues map to be
>>> populated.  One option would make all option instances aware of 
>>> their parent
>>> and so make it easy to identify the path, unfortunately this means 
>>> that the
>>> same option/group can't appear in multiple places within the 
>>> structure which
>>> is a useful feature IMHO.  Perhaps the easiest solution is to make 
>>> all the
>>> process(..) methods take an additional Path argument.  This way, as 
>>> control
>>> is delegated to other arguments / children / group members, the 
>>> appropriate
>>> Path can be constructed based on the one passed in and can be passed 
>>> to the
>>> delagate's process method.
>>> Begin able to deal with option paths is also relevant to processing
>>> Properties / Prefs / xml / etc into a CommandLine.  Given a property
>>> "topleft.x" we need to first verify that the path topleft>x is valid 
>>> and
>>> then associate any values / switches in the CommandLine.  I guess the
>>> easiest thing here would be to add a method in Option along the lines
>>> of:
>>>     /** Finds the option associated with the path from this option or
>>>      *  null if the path is invalid
>>>      */
>>>     Option find(Path path);

Yeah sounds good.

>>> This is fine if the we can use the properties to drive the options 
>>> but this
>>> might not always be the best way forward but adding another method 
>>> to Option
>>> to find the valid paths should allow options to drive the prefs too.
>>>     /** Finds all the valid option paths rooted at this option */
>>>     Set findPaths();

I get the feeling I'm being dozy again.  I think this would be a good 
for testing but can you explain why we would need this method defined on
the API?

-John K

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message