Spring Custom Property Editor

1. Introduksjon

Enkelt sagt, Spring bruker eiendomsredaktører tungt for å administrere konvertering mellom String verdier og tilpassing Gjenstand typer; dette er basert på Java Beans PropertyEditor.

I denne opplæringen vil vi gå over to forskjellige brukssaker for å demonstrere automatisk binding av eiendomsredaktør og tilpasset eiendomsredigering.

2. Automatisk innbinding av eiendomsredaktør

Standard JavaBeans infrastruktur vil automatisk oppdage PropertyEditor klasser hvis de er i samme pakke som klassen de håndterer. Disse må også ha samme navn som den klassen pluss Redaktør suffiks.

For eksempel hvis vi oppretter en Kredittkort modellklasse, så bør vi kalle redaktørklassen CreditCardEditor.

La oss nå gå gjennom et praktisk eiendomsforbindende eksempel.

I vårt scenario sender vi et kredittkortnummer som en stivariabel i forespørselens URL, og vi binder den verdien som et kredittkort gjenstand.

La oss først lage Kredittkort modellklasse som definerer felt rawCardNumber, Bankidentifikasjonsnummer (de første seks sifrene), kontonummer (sifrene fra 7 til 15) og sjekkekoden (siste siffer):

offentlig klasse CreditCard {private String rawCardNumber; privat HeltalsbankIdNo; privat Heltall konto Nei; privat Heltall sjekkode; // standard konstruktør, getters, setters}

Deretter oppretter vi CreditCardEditor klasse. Dette implementerer forretningslogikken for å konvertere kredittkortnummeret gitt som en String til en Kredittkort gjenstand.

Eiendomsredaktørklassen bør utvides PropertyEditorSupport og implementere getAsText () og setAsText () metoder:

offentlig klasse CreditCardEditor utvider PropertyEditorSupport {@Override public String getAsText () {CreditCard creditCard = (CreditCard) getValue (); return creditCard == null? "": creditCard.getRawCardNumber (); } @ Override public void setAsText (String text) kaster IllegalArgumentException {if (StringUtils.isEmpty (text)) {setValue (null); } annet {CreditCard creditCard = new CreditCard (); creditCard.setRawCardNumber (tekst); StrengkortNr = text.replaceAll ("-", ""); if (cardNo.length ()! = 16) throw new IllegalArgumentException ("Credit card format should be xxxx-xxxx-xxxx-xxxx"); prøv {creditCard.setBankIdNo (Integer.valueOf (cardNo.substring (0, 6))); creditCard.setAccountNo (Integer.valueOf (cardNo.substring (6, cardNo.length () - 1))); creditCard.setCheckCode (Integer.valueOf (cardNo.substring (cardNo.length () - 1))); } catch (NumberFormatException nfe) {throw new IllegalArgumentException (nfe); } setValue (creditCard); }}}

De getAsText () metoden kalles når du serialiserer et objekt til en Streng, samtidig som setAsText () brukes til å konvertere en String til et annet objekt.

Siden disse klassene ligger i samme pakke, trenger vi ikke gjøre noe annet for å binde Redaktør for type Kredittkort.

Vi kan nå avsløre dette som en ressurs i et REST API; operasjonen tar et kredittkortnummer som en variabel for forespørselsbanen, og Spring vil binde den tekstverdien som en CrediCard motsette og sende det som et metodeargument:

@GetMapping (value = "/ credit-card / {card-no}", produserer = MediaType.APPLICATION_JSON_UTF8_VALUE) offentlig CreditCard parseCreditCardNumber (@PathVariable ("card-no") CreditCard creditCard) {return creditCard; }

For eksempel for en eksempel-URL / eiendomsredaktør / kredittkort / 1234-1234-1111-0019, vi får svaret:

{"rawCardNumber": "1234-1234-1111-0011", "bankIdNo": 123412, "accountNo": 341111001, "checkCode": 9}

3. Binding av egendefinert eiendomsredaktør

Hvis vi ikke har den påkrevde typeklassen og eiendomsredaktørklassen i samme pakke eller med de forventede navnekonvensjonene, må vi definere en tilpasset binding mellom den nødvendige typen og eiendomseditoren.

I vårt bindingsscenario for tilpasset eiendomsredaktør, String verdien sendes i URL-en som sti-variabel, og vi binder den verdien som en ExoticType objekt som bare holder verdien som et attributt.

Som i avsnitt 2, la oss først lage en modellklasse ExoticType:

offentlig klasse ExoticType {privat strengnavn; // standard konstruktør, getters, setters}

Og vår tilpassede eiendomsredaktørklasse CustomExoticTypeEditor som igjen strekker seg PropertyEditorSupport:

offentlig klasse CustomExoticTypeEditor utvider PropertyEditorSupport {@Override public String getAsText () {ExoticType exoticType = (ExoticType) getValue (); returner eksotisk Type == null? "": exoticType.getName (); } @ Override public void setAsText (Strengtekst) kaster IllegalArgumentException {ExoticType exoticType = new ExoticType (); exoticType.setName (text.toUpperCase ()); setValue (eksotisk Type); }}

Siden Spring ikke kan oppdage eiendomsredaktøren, vi trenger en metode merket med @InitBinder i vår Kontroller klasse som registrerer redaktøren:

@InitBinder offentlig ugyldig initBinder (WebDataBinder bindemiddel) {binder.registerCustomEditor (ExoticType.class, ny CustomExoticTypeEditor ()); }

Da kan vi binde brukerinngangen til ExoticType gjenstand:

@GetMapping (verdi = "/ eksotisk-type / {verdi}", produserer = MediaType.APPLICATION_JSON_UTF8_VALUE) offentlig ExoticType parseExoticType (@PathVariable ("verdi") ExoticType eksotisk Type) {return eksotisk Type; }

For URL-forespørsel om eksempel / eiendomsredaktør / eksotisk type / lidenskapsfrukt, vi får prøvesvaret:

{"name": "PASSION-FRUIT"}

4. Konklusjon

I denne raske artikkelen så vi hvordan vi kunne bruke automatisk og tilpasset eiendomseditorbinding for å konvertere menneskelig String verdier til komplekse Java-typer.

Den fulle kildekoden til eksemplene våre her er som alltid over på GitHub.