Analyse af kommandolinjeparametre med flyselskab
1. Introduktion
I denne vejledning vi introducerer Airline - et annotationsdrevet Java-bibliotek til opbygning af kommandolinjegrænseflader (CLI'er).
2. Scenarie
Når du bygger en kommandolinjeapplikation, er det naturligt at oprette en simpel grænseflade, der giver brugeren mulighed for at forme output efter behov. Næsten alle har spillet med Git CLI og kan forholde sig til hvor kraftig, men alligevel enkel, den er. Ak, få værktøjer er nyttige, når man bygger en sådan grænseflade.
Flyselskabetsigter mod at reducere kogepladekoden, der typisk er knyttet til CLI'er i Java, da de fleste almindelige adfærd kan opnås med annoteringer og nul brugerkode.
Vi skal implementere et lille Java-program, der udnytter flyselskabets funktionalitet til at efterligne en fælles CLI. Det udsætter brugerkommandoer til opsætning af vores programkonfiguration, som f.eks. At definere database-URL, legitimationsoplysninger og loggernøjagtighed. Vi dykker også under overfladen af vores bibliotek og bruger mere end dets grundlæggende til at undersøge, om det kan håndtere en vis kompleksitet.
3. Opsætning
For at komme i gang, lad os tilføje flyselskabsafhængighed til vores pom.xml:
com.github.rvesse flyselskab 2.7.2 4. En simpel CLI
Lad os oprette vores startpunkt for applikationen - 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) ; Kørbar cmd = cli.parse (args); cmd.run (); }}Gennem en simpel @Cli bemærkning, vi har defineret den standardkommando, der kører på vores applikation - Hjælp kommando.
Det Hjælp klasse kommer som en del af Airline-biblioteket og udsætter en standardhjælpskommando ved hjælp af -h eller -Hjælp muligheder.
Ligesom det er den grundlæggende opsætning færdig.
5. Vores første kommando
Lad os implementere vores første kommando, en simpel LoggingCommand klasse, der vil kontrollere viden om vores logfiler. Vi kommenterer klassen med @Kommando for at sikre, at den korrekte kommando anvendes, når brugeren ringer setup-log:
@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") privat boolsk verbose = false; @Override public void run () {if (! Help.showHelpIfRequested ()) System.out.println ("Nøjagtighed:" + detaljeret); }}}Lad os se nærmere på vores eksempelkommando.
For det første har vi indstillet en beskrivelse, så vores hjælper takket være injektionen viser vores kommandomuligheder, når det bliver bedt om det.
Så erklærede vi en boolsk variabel, ordrigog kommenterede det med @Mulighed at give det et navn, en beskrivelse og også et alias -v / –verbose for at repræsentere vores kommandolinjemulighed for at kontrollere bredhed.
Endelig inde i løb metode, instruerede vi vores kommando om at stoppe, når brugeren beder om hjælp.
Så langt så godt. Nu skal vi tilføje vores nye kommando til hovedgrænsefladen ved at ændre @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); Kørbar cmd = cli.parse (args); cmd.run (); }} Nu, hvis vi passerer setup-log -v til vores program, vil det køre vores logik.
6. Begrænsninger og mere
Vi har set, hvordan Airline genererer CLI fejlfrit, men ... der er mere!
Vi kan specificere begrænsninger (eller begrænsninger) for vores parametre til at håndtere tilladte værdier, krav eller afhængigheder med mere.
Vi opretter en DatabaseSetupCommand klasse, som vil reagere på setup-db kommando; det samme som vi gjorde tidligere, men vi tilføjer noget krydderi.
Først anmoder vi om typen af database og accepterer kun 3 gyldige værdier igennem @AllowedRawValues:
@AllowedRawValues (allowValues = {"mysql", "postgresql", "mongodb"}) @Option (type = OptionType.COMMAND, name = {"-d", "--database"}, description = "Type af RDBMS. ", title =" RDBMS type: mysql | postgresql | mongodb ") beskyttet String rdbmsMode;Når du bruger en databaseforbindelse, bør brugerne uden tvivl angive et slutpunkt og nogle legitimationsoplysninger for at få adgang til det. Vi lader CLI håndtere dette gennem en (URL-tilstand) eller flere parametre (værtstilstand). Til dette bruger vi @MutuallyExclusiveWith kommentar, der markerer hver parameter med det samme tag:
@Option (type = OptionType.COMMAND, navn = {"--rdbms: url", "--url"}, beskrivelse = "URL, der skal bruges til forbindelse til RDBMS.", Title = "RDBMS URL") @MutuallyExclusiveWith ( tag = "mode") @Pattern (mønster = "^ (//.*) :( d *) (. *) u = (. *) & p = (. *)") beskyttet streng rdbmsUrl = ""; @Option (type = OptionType.COMMAND, navn = {"--rdbms: host", "--host"}, beskrivelse = "Host, der skal bruges til forbindelse til RDBMS.", Title = "RDBMS host") @MutuallyExclusiveWith ( tag = "mode") beskyttet String rdbmsHost = ""; Bemærk, at vi brugte @Mønster dekoratør, som hjælper os med at definere URL-strengformatet.
Hvis vi ser på projektdokumentationen, finder vi anden værdifulde værktøjer til håndtering af krav, hændelser, tilladte værdier, specifikke sager og mere, så vi kan definere vores brugerdefinerede regler.
Endelig, hvis brugeren valgte værtsfunktionen, skal vi bede dem om at give deres legitimationsoplysninger. På denne måde er en mulighed afhængig af en anden. Vi kan opnå denne adfærd med @RequiredOnlyIf kommentar:
@RequiredOnlyIf (names = {"- rdbms: host", "--host"}) @Option (type = OptionType.COMMAND, name = {"--rdbms: user", "-u", "--user "}, beskrivelse =" Bruger til login til RDBMS. ", title =" RDBMS bruger ") beskyttet String rdbmsUser; @RequiredOnlyIf (names = {"- rdbms: host", "--host"}) @Option (type = OptionType.COMMAND, name = {"--rdbms: password", "--password"}, beskrivelse = "Adgangskode til login til RDBMS.", Title = "RDBMS password") beskyttet String rdbmsPassword; Hvad hvis vi har brug for nogle drivere til at håndtere DB-forbindelsen? Antag også, at vi har brug for at modtage mere end en værdi i en enkelt parameter. Vi kan bare ændre valgmulighedstypen til OptionType.ARGUMENTS eller - endnu bedre - accepter en liste over værdier:
@Option (type = OptionType.COMMAND, navn = {"--driver", "--jars"}, beskrivelse = "Liste over drivere", title = "--driver --driver") beskyttede List jars = ny ArrayList ();Lad os ikke glemme at tilføje kommandoen til databaseopsætning til vores hovedklasse. Ellers vil den ikke være tilgængelig på CLI.
7. Kør
Vi gjorde det! Vi er færdige med vores projekt, og nu kan vi køre det.
Som forventet uden at videregive nogen parametre Hjælp påberåbes:
$ baeldung-cli-brug: baeldung-cli [] Kommandoer er: hjælp Vis hjælpoplysninger opsætning-db Opsæt vores database opsætnings-log Opsæt vores log Se 'baeldung-cli hjælp' for mere information om en bestemt kommando.Hvis vi i stedet udfører setup-log - hjælp, vi får:
$ baeldung-cli setup-log --help NAVN baeldung-cli setup-log - Opsæt vores log SYNOPSIS baeldung-cli setup-log [-h] [-v] OPTIONS -h, --help Vis hjælpoplysninger -v, - -verbose Sæt log-bredde til / fraEndelig vil levering af parametre til disse kommandoer køre den korrekte forretningslogik.
8. Konklusion
I denne artikel har vi bygget en enkel men alligevel kraftig kommandolinjegrænseflade med meget lidt kodning.
Luftfartsbiblioteket med sine kraftfulde funktioner forenkler CLI og giver os en generel, ren og genanvendelig infrastruktur. Det giver os, udviklere, mulighed for at koncentrere sig om vores forretningslogik snarere end at bruge tid på at designe, hvad der skal være trivielt.
Som altid kan koden findes på GitHub.
