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 21:58:10 GMT

----- Original Message ----- 
From: "John Keyes" <jbjk@mac.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Sunday, November 02, 2003 9:04 PM
Subject: Re: [CLI] 2.x Tasks


> >>>> 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?
> Yeap.
>
> >>> 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

So use a String instead of some new fangled Path object?  Seems reasonable
enough, although the [1] style indexing might lead to other xpath style
expectation.  Not thought about that too much though.

>
> Should we drop the support for the trigger? So regardless of the
> trigger could we retrieve values without it:
>
>    getValue("topleft");

I kind of like using the triggers as they add lots of flexibility but the
number of method overloadings for convenience is pretty high.

>
> internally if the string does not contain any '/' we search for
> "/topleft".  This will give us a single means of retrieving the
> values.
>
> (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
> method
> for testing but can you explain why we would need this method defined on
> the API?

It's probably not necessary.  The thinking was that when the preferences
have loads of values (thinking windows Registry as an example) it would be
impractical to iterate over all them and say "does this refer to an
option?".  Instead the findPaths() method would allow them to query the root
option and use those values to search the preferences.

Cheers,

Rob

>
> Thanks,
> -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


Mime
View raw message