Custom Validation MessageSource i Spring Boot

1. Oversikt

MessageSource er en kraftig funksjon tilgjengelig i vårapplikasjoner. Dette hjelper applikasjonsutviklere med å håndtere forskjellige komplekse scenarier med å skrive mye ekstra kode, for eksempel miljøspesifikk konfigurasjon, internasjonalisering eller konfigurerbare verdier.

Et scenario til kan være å endre standardvalideringsmeldingene til mer brukervennlige / tilpassede meldinger.

I denne veiledningen, vi får se hvordan du konfigurerer og administrerer tilpasset validering MessageSource i applikasjonen ved hjelp av Spring Boot.

2. Maven-avhengigheter

La oss begynne med å legge til de nødvendige Maven-avhengighetene:

 org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-validering 

Du finner de nyeste versjonene av disse bibliotekene på Maven Central.

3. Eksempel på tilpasset bekreftelsesmelding

La oss vurdere et scenario der vi må utvikle et program som støtter flere språk. Hvis brukeren ikke oppgir de riktige detaljene som inndata, vil vi vise feilmeldinger i henhold til brukerens lokalitet.

La oss ta et eksempel på en påloggingsskjema:

public class LoginForm {@NotEmpty (message = "{email.notempty}") @Email private String email; @NotNull privat strengpassord; // standard getter og setters}

Her har vi lagt til valideringsbegrensninger som bekrefter om en e-post ikke er gitt i det hele tatt, eller ikke, men ikke følger standard e-postadressestil.

For å vise tilpasset og stedsspesifikk melding, kan vi tilby en plassholder som nevnt for @Ikke tom kommentar.

De e-post. ikke fristende eiendommen blir løst fra en eiendomsfiler av MessageSource konfigurasjon.

4. Definere MessageSource Bønne

En applikasjonskontekst delegerer meldingsoppløsningen til en bønne med nøyaktig navn messageSource.

ReloadableResourceBundleMessageSource er den vanligste MessageSource implementering som løser meldinger fra ressurspakker for forskjellige lokaliteter:

@Bean public MessageSource messageSource () {ReloadableResourceBundleMessageSource messageSource = new ReloadableResourceBundleMessageSource (); messageSource.setBasename ("classpath: messages"); messageSource.setDefaultEncoding ("UTF-8"); returmeldingKilde; }

Her er det viktig å gi basenavn ettersom stedsspesifikke filnavn vil bli løst basert på det oppgitte navnet.

5. Definere LocalValidatorFactoryBean

For å bruke egendefinerte navnemeldinger i en egenskapsfil, må vi definere en LocalValidatorFactoryBean og registrer meldingKilde:

@Bean public LocalValidatorFactoryBean getValidator () {LocalValidatorFactoryBean bean = ny LocalValidatorFactoryBean (); bean.setValidationMessageSource (messageSource ()); retur bønne; }

Vær imidlertid oppmerksom på at hvis vi allerede hadde utvidet WebMvcConfigurerAdapter, for å unngå å ignorere den egendefinerte validatoren, må vi stille validatoren ved å overstyre getValidator () metode fra foreldreklassen.

Nå kan vi definere en eiendomsmelding som:

email.notempty = ”

i stedet for

“Javax.validation.constraints.NotEmpty.message =”

6. Definere eiendomsfiler

Det siste trinnet er å lage en eiendomsfil i src / main / resources katalog med navnet gitt i basenavn i trinn 4:

# messages.properties email.notempty = Oppgi gyldig e-post-ID.

Her kan vi dra nytte av internasjonalisering sammen med dette. La oss si at vi vil vise meldinger til en fransk bruker på deres språk.

I dette tilfellet må vi legge til en eiendomsfil til med navnet messages_fr.properties på samme sted (ingen kodeendringer nødvendig i det hele tatt):

# messages_fr.properties email.notempty = Veuillez fournir un identifiant de messagerie valide.

7. Konklusjon

I denne artikkelen dekket vi hvordan standardvalideringsmeldingene kan endres uten å endre koden hvis konfigurasjonen er gjort riktig på forhånd.

Vi kan også utnytte støtten til internasjonalisering sammen med dette for å gjøre applikasjonen mer brukervennlig.

Som alltid er hele kildekoden tilgjengelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found