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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
