-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sub-subcommands (nested commands) #127
Comments
@pditommaso Apologies I misread your question. You can register multiple subcommands, and picocli will recognize command line arguments containing multiple subcommands, but picocli currently does not impose a hierarchy on subcommands. So, it is not possible to have a subcommand XYZ that is only recognized after previously a "parent" subcommand ABC was recognized. Example:
In your application you can now choose to throw an exception if XYZ is only valid after an ABC subcommand. Does that work for you? |
It could be a workaround but it's not exactly what I'm trying to do. I have a use case in which a command can have subcommands and in some cases there could be sub-subcommands with the same name but different semantic, thus I would need to keep the implementation logic separated. |
Ok this sounds doable. Parsing and usage help-wise the current code will need only small modifications. Still thinking about what the API for registering nested subcommands should look like. I like the method chaining that the current API affords, meaning that the One idea is to make the first parameter of
What do you think? Is it easy to see intuitively what the above code does? |
Yes, this sounds cool! |
...or should there be a separate method?
A separate method raises the question of what signature it should have. And I just realized that neither of these will work because a vararg must be the last parameter. :-) Oops. |
Ok, so the above won't work because the varargs must come last. So now I'm thinking of something like the below, but I don't like the ambiguity of
|
I tend to prefer the previous syntax but I understand the limitation of open arrays. What it the sub-subcommands are specified by using a The more elegant solution would be to add sub-command directly on a command eg.
But it would require commands to implement a command abstract class or even better an interface with a default method (which implies only Java 8). |
Yes, there should be no need to implement any interfaces or do anything other than the normal annotations for nested subcommands. Ease of use is one of the drivers of this project, so where possible I like to provide a fluent API to allow method call chaining. One idea is to wrap commands in a
The good thing is that this way there is no ambiguity about which is a subcommand of which. The disadvantage is this may be a bit confusing because you need to create the most deeply nested command first. The hierarchy is more obvious when written in a fluent way like this:
|
I like this approach, this would allow each command to provide its own graph of subcommands, in a very OOP way. |
…erying the full nested subcommand hierarchy
@pditommaso I just pushed this to master. Can you verify? If you can contribute tests that would be great. |
Regarding custom type converters, the common use case is likely that they should apply to all nested subcommands. However, it should be possible to have a custom type converter apply only to one of the subcommands (or not apply to one of the subcommands). To achieve this, custom type converters are applied to the full subcommand hierarchy as it exists when the type converter is registered. Subcommands added later won't automatically have this type converter. Updated the user manual and javadoc to explain the above. |
I've added a test for sub-subcommands, but I can't manage to make it work. This test returns 1 instead of 3. I guess I make some trivial mistake but I can manage to figure out what's the problem. One more thing: Do you know Spock framework? Would it be fine for you if I use it for contributing tests? |
@pditommaso Yes Spock is fine.
I have made this exact same mistake several times myself... |
Oops, you are right. But this bring a new question: should not an exception raised when an command/option is specified ? |
Probably yes. I was thinking along these lines: #132. Feedback very welcome! |
Great last thing, how is your imports IDE configuration? I've noticed that my IntelliJ IDEA configuration is completely reorganising all imports. |
Exporting my IntelliJ IDEA 2017.1.2 Editor > Codestyle > Java > scheme gives this:
|
@pditommaso Just checking in, how are things going with the tests? I may do a release soon (in the next few days) after implementing the remaining tickets to improve validation (#132 and #138). We can always add the tests later if you prefer but I can hold off for a little bit and include them in the release. |
Sorry, I'm very busy this week and I couldn't progress on tests. I will try to catch up in the weekend. |
Closing this ticket since the functionality has been implemented and version 0.9.7 has been release. |
Quick question: Is it possible to define a subcommand of a subcommand ?
The text was updated successfully, but these errors were encountered: