streamalism.org

1. Introduksjon

I denne veiledningen, vi introduserer Airline - et kommentordrevet Java-bibliotek for å bygge kommandolinjegrensesnitt (CLI).

2. Scenario

Når du bygger et kommandolinjeprogram, er det naturlig å lage et enkelt grensesnitt for å la brukeren forme utdataene etter behov. Nesten alle har spilt med Git CLI og kan forholde seg til hvor kraftig, men likevel enkel den er. Akk, få verktøy er nyttige når du bygger et slikt grensesnitt.

Flyselskapethar som mål å redusere kokerplatekoden som vanligvis er knyttet til CLI-er i Java, ettersom de vanligste atferdene kan oppnås med merknader og null brukerkode.

Vi skal implementere et lite Java-program som vil utnytte flyselskapets funksjoner for å etterligne en felles CLI. Det vil utsette brukerkommandoer for å konfigurere programkonfigurasjonen vår, som å definere URL-adressen til databasen, legitimasjonen og loggførheten. Vi vil også dykke under overflaten av biblioteket vårt og bruke mer enn det grunnleggende for å undersøke om det kan takle noe kompleksitet.

3. Oppsett

For å komme i gang, la oss legge til flyavhengigheten til vår pom.xml:

 com.github.rvesse flyselskap 2.7.2 

4. En enkel CLI

La oss lage vårt inngangspunkt for applikasjonen - Kommandolinje klasse:

@Cli (name = "baeldung-cli", description = "Baeldung Airline Tutorial", defaultCommand = Help.class) public class CommandLine {public static void main (String [] args) {Cli cli = new Cli (CommandLine.class) ; Kjørbar cmd = cli.parse (args); cmd.run (); }}

Gjennom en enkel @Cli merknad, har vi definert standardkommandoen som skal kjøres på applikasjonen vår - Hjelp kommando.

De Hjelp klasse kommer som en del av Airline-biblioteket og avslører en standard hjelpekommando ved hjelp av -h eller -hjelp alternativer.

Akkurat slik er det grunnleggende oppsettet gjort.

5. Vår første kommando

La oss implementere vår første kommando, en enkel LoggingCommand klasse som vil kontrollere detaljene i loggene våre. Vi kommenterer klassen med @Kommando for å sikre at riktig kommando blir brukt når brukeren ringer oppsett-logg:

@Command (name = "setup-log", description = "Setup our log") offentlig klasse LoggingCommand implementerer Runnable {@Inject private HelpOption help; @Option (name = {"-v", "--verbose"}, description = "Set log verbosity on / off") private boolean verbose = false; @Override public void run () {if (! Help.showHelpIfRequested ()) System.out.println ("Ordlighetsgrad:" + ordentlig); }}}

La oss se nærmere på eksemplet på kommandoen.

Først har vi satt en beskrivelse slik at hjelperen vår, takket være injeksjonen, vil vise kommandoalternativene våre når det blir bedt om det.

Så erklærte vi en boolsk variabel, utdypende, og kommenterte den med @Alternativ å gi den et navn, en beskrivelse, og også et alias -v / –verbose for å representere kommandolinjealternativet vårt for å kontrollere detaljnivået.

Til slutt, inne i løpe metoden, instruerte vi kommandoen vår om å stoppe når brukeren ber om hjelp.

Så langt så bra. Nå må vi legge til vår nye kommando i hovedgrensesnittet ved å endre @Cli kommentar:

@Cli (name = "baeldung-cli", description = "Baeldung Airline Tutorial", defaultCommand = Help.class, commands = {LoggingCommand.class, Help.class}) public class CommandLine {public static void main (String [] args ) {Cli cli = ny Cli (CommandLine.class); Kjørbar cmd = cli.parse (args); cmd.run (); }} 

Nå, hvis vi passerer oppsett-logg -v til vårt program, vil det kjøre vår logikk.

6. Begrensninger og mer

Vi har sett hvordan Airline genererer CLI feilfritt, men ... det er mer!

Vi kan spesifisere begrensninger (eller begrensninger) for parametrene våre for å håndtere tillatte verdier, krav eller avhengigheter og mer.

Vi skal lage en DatabaseSetupCommand klasse, som vil svare på oppsett-db kommando; det samme som vi gjorde tidligere, men vi vil legge til litt krydder.

Først ber vi om hvilken type database som bare godtar 3 gyldige verdier @AllowedRawValues:

@AllowedRawValues ​​(allowValues ​​= {"mysql", "postgresql", "mongodb"}) @Option (type = OptionType.COMMAND, name = {"-d", "--database"}, description = "Type RDBMS. ", title =" RDBMS type: mysql | postgresql | mongodb ") beskyttet String rdbmsMode;

Når du bruker en databasetilkobling, bør brukerne uten tvil oppgi et sluttpunkt og noen legitimasjon for å få tilgang til det. Vi lar CLI håndtere dette gjennom en (URL-modus) eller flere parametere (vertsmodus). For dette bruker vi @MutuallyExclusiveWith merknad, og markerer hver parameter med samme tag:

@Option (type = OptionType.COMMAND, name = {"--rdbms: url", "--url"}, description = "URL for bruk for tilkobling til RDBMS.", Title = "RDBMS URL") @MutuallyExclusiveWith ( tag = "mode") @Pattern (mønster = "^ (//.*) :( d *) (. *) u = (. *) & p = (. *)") beskyttet streng rdbmsUrl = ""; @Option (type = OptionType.COMMAND, name = {"--rdbms: host", "--host"}, description = "Host å bruke for tilkobling til RDBMS.", Title = "RDBMS host") @MutuallyExclusiveWith ( tag = "mode") beskyttet String rdbmsHost = ""; 

Merk at vi brukte @Mønster dekoratør, som hjelper oss med å definere URL-strengformatet.

Hvis vi ser på prosjektdokumentasjonen, finner vi annen verdifulle verktøy for å håndtere krav, forekomster, tillatte verdier, spesifikke saker og mer, slik at vi kan definere våre tilpassede regler.

Til slutt, hvis brukeren valgte vertsmodus, bør vi be dem om å oppgi legitimasjon. På denne måten er ett alternativ avhengig av et annet. Vi kan oppnå denne oppførselen med @RequiredOnlyIf kommentar:

@RequiredOnlyIf (names = {"- rdbms: host", "--host"}) @Option (type = OptionType.COMMAND, name = {"--rdbms: user", "-u", "--user "}, beskrivelse =" Bruker for pålogging til RDBMS. ", title =" RDBMS bruker ") beskyttet String rdbmsUser; @RequiredOnlyIf (names = {"- rdbms: host", "--host"}) @Option (type = OptionType.COMMAND, name = {"--rdbms: password", "--password"}, description = "Passord for pålogging til RDBMS.", Title = "RDBMS passord") beskyttet String rdbmsPassword; 

Hva om vi trenger å bruke noen drivere til å håndtere DB-tilkoblingen? Anta også at vi trenger å motta mer enn én verdi i en enkelt parameter. Vi kan bare endre alternativtypen til OptionType.ARGUMENTS eller - enda bedre - godta en liste over verdier:

@Option (type = OptionType.COMMAND, name = {"--driver", "--jars"}, description = "List of drivers", title = "--driver --driver") beskyttede Listkrukker = ny ArrayList ();

La oss ikke glemme å legge til kommandoen for databaseoppsett i hovedklassen vår. Ellers vil den ikke være tilgjengelig på CLI.

7. Løp

Vi gjorde det! Vi avsluttet prosjektet vårt, og nå kan vi kjøre det.

Som forventet, uten å overføre noen parametere, Hjelp påkalles:

$ baeldung-cli bruk: baeldung-cli [] Kommandoer er: hjelp Vis hjelpinformasjon oppsett-db Sett opp vår database oppsett-logg Oppsett vår logg Se 'baeldung-cli hjelp' for mer informasjon om en spesifikk kommando.

Hvis vi i stedet utfører setup-log –help, vi får:

$ baeldung-cli setup-log --help NAVN baeldung-cli setup-log - Sett opp loggen vår SYNOPSIS baeldung-cli setup-log [-h] [-v] ALTERNATIV -h, --help Vis hjelpinformasjon -v, - -verbose Slå loggformighet på / av

Til slutt vil tilførsel av parametere til disse kommandoene kjøre den korrekte forretningslogikken.

8. Konklusjon

I denne artikkelen har vi bygget et enkelt, men kraftig kommandolinjegrensesnitt med veldig lite koding.

Airline-biblioteket, med sine kraftige funksjoner, forenkler CLI, og gir oss en generell, ren og gjenbrukbar infrastruktur. Det lar oss utviklere konsentrere seg om vår forretningslogikk i stedet for å bruke tid på å designe det som skal være trivielt.

Som alltid kan koden bli funnet på GitHub.