Make CommandRegistration.Builder matching with new SecurityFilterChain builder format
heavynimbus opened this issue · 1 comments
heavynimbus commented
Hi,
I think CommandRegistration.Builder can be upgraded by following new SecurityFilterChain's builder usage from Spring Security
@Bean
public CommandRegistration myCommand() {
return CommandRegistration.builder()
.command("my-command")
.withOption()
.longName("option1")
.required()
.type(String.class)
.and()
.withOption()
.longName("option1")
.required()
.type(String.class)
.and()
.withTarget()
.consumer(ctx -> ctx.getTerminal().writer().println("Hello World"))
.and()
.build();
}
Could became:
@Bean
public CommandRegistration myCommand() {
return CommandRegistration.builder()
.command("my-command")
.withOption(optionCustomizer ->
optionCustomizer.longName("option1")
.required()
.type(String.class)
)
.withOption(optionCustomizer ->
optionCustomizer.longName("option2")
.required()
.type(String.class)
)
.withTarget(targetCustomizer ->
targetCustomizer.consumer(ctx -> ctx.getTerminal().writer().println("Hello World"))
)
.build();
}
This could be done for withOption
, withTarget
, withAlias
, withErrorHandling
, withHelpOption
and withExitCode
I think this makes for more readable code and allows for better indentation for automated formatters
Thank's for reading :)
jvalkeal commented
Without looking into details this sounds like a good idea.
While you don't need to chain "dsl type javaconfig" together order to get better programmatic access I've always disliked that approach as config then starts to look a bit cluttered. Taking idea from a Spring Security for lambda style makes that part more clean.