commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <j...@mac.com>
Subject Re: [CLI] 2.x Tasks
Date Sun, 02 Nov 2003 19:35:02 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.
>
> 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.

Cheers,
-John K

> 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);
> 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();
>
> Thoughts ?
>
> Rob
>
>
>>
>> -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