DataBinder

Անոթացիաներով @Controller կամ @ControllerAdvice դասերը կարող են ունենալ մեթոդներ, որոնք նշված են @InitBinder անոթացիայով, որոնք ինիցիալիզացնում են WebDataBinder ից՝ որոնք կարող են.

• Կցել հարցման պարամետրերը (այսինքն՝ ֆորմայի կամ հարցման տվյալները) մոդելի օբյեկտին:

• Փոխարկում հարցման տողային արժեքները (օրինակ՝ հարցման պարամետրեր, ճանապարհի փոփոխականներ, վերնագրեր, cookie տվյալներ և այլն) վերահսկիչ մեթոդի նպատակային պրոտոտիպի:

• Ֆորմատավորում մոդելի օբյեկտների արժեքները որպես String արժեքներ, երբ ցուցադրվում են HTML-ֆորմեր:

@InitBinder անոթացիայով մեթոդները կարող են գրանցել վերահսկիչի համար հատուկ java.beans.PropertyEditor կամ Converter և Formatter Spring-ից: Բացի այդ, կարող եք օգտագործել MVC-ի կարգավորումները՝ գրանցելու համար Converter և Formatter տիպերը գլոբալ կիսվող FormattingConversionService-ում:

@InitBinder անոթացիայով նշված մեթոդները աջակցում են նույնատիպ բազմաթիվ արգումենտներ, ինչպիսիք են @RequestMapping անոթացիայով մեթոդները, բացառությամբ @ModelAttribute (հրամանի օբյեկտ) անոթացիայով արգումենտների: Սովորաբար, դրանք հայտարարվում են WebDataBinder արգումենտով (գրանցման ընթացակարգերի համար) և վերադարձվող արժեքով void : Հաջորդ օրինակով դա ցույց է տալիս.

@Controller
public class FormController {
    @InitBinder 
    public void initBinder(WebDataBinder binder) {
        SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
        dateFormat.setLenient(false);
        binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat, false));
    }
    // ...
}

1. @InitBinder անոթացիայով մեթոդի սահմանում.

@Controller
class FormController {
    @InitBinder 
    fun initBinder(binder: WebDataBinder) {
        val dateFormat = SimpleDateFormat("yyyy-MM-dd")
        dateFormat.isLenient = false
        binder.registerCustomEditor(Date::class.java, CustomDateEditor(dateFormat, false))
    }
    // ...
}

1. @InitBinder անոթացիայով մեթոդի սահմանում.

Բացի այդ, եթե դուք օգտագործում եք Formatter-ի հիման վրա կարգավորումը ընդհանուր FormattingConversionService-ի միջոցով, ապա կարող եք կրկին օգտագործել նույն մոտեցումը և գրանցել վերահսկիչի համար հատուկ Formatter իրականացման օրինակ, ինչպես ցույց է տրված հետևյալ օրինակով.

@Controller
public class FormController {
    @InitBinder 
    protected void initBinder(WebDataBinder binder) {
        binder.addCustomFormatter(new DateFormatter("yyyy-MM-dd"));
    }
    // ...
}

1. @InitBinder անոթացիայով մեթոդի սահմանում հատուկ ձևակերպիչի համար:

@Controller
class FormController {
    @InitBinder 
    protected fun initBinder(binder: WebDataBinder) {
        binder.addCustomFormatter(DateFormatter("yyyy-MM-dd"))
    }
    // ...
}

1. @InitBinder անոթացիայով մեթոդի սահմանում հատուկ ձևակերպիչի համար:

Մոդելի կառուցվածքը

Վեբ-հավելվածների համատեքստում տվյալների կցում ենթադրում է HTTP հարցման պարամետրերի (այսինքն՝ ֆորմայի կամ հարցման պարամետրերի տվյալների) կցումը մոդելի օբյեկտի և նրա ներդրված օբյեկտների հատկություններին:

Տվյալների կցման համար բացվում են միայն public հատկությունները, որոնք համապատասխանում են JavaBeans անվանման կանոններին՝ օրինակ, public String getFirstName() և public void setFirstName(String) մեթոդները firstName հատկության համար:

Նախնական կարգավորմամբ, Spring-ը թույլ է տալիս կցում բոլոր public հատկություններին մոդելի օբյեկտների գրաֆում: Սա նշանակում է, որ անհրաժեշտ է ուշադիր մտածել, թե ինչ public հատկություններ ունի մոդելում, որովհետև հաճախորդը կարող է նպատակ ունենալ յուրաքանչյուր public հատկություն, նույնիսկ այն, որը չի ենթադրվում տվյալ օգտագործման դեպքի համար:

Օրինակ, եթե առկա է HTTP ֆորմայի տվյալների վերջնական կետ, վնասակար հաճախորդը կարող է փոխանցել արժեքներ մոդելի օբյեկտների գրաֆում առկա հատկությունների համար, բայց որոնք չեն հանդիսանում HTML ֆորմայում ներկայացված բրաուզերում: Սա կարող է հանգեցնել մոդելի օբյեկտի և նրա ցանկացած ներդրված օբյեկտի տվյալների փոփոխման, որին չի սպասվում:

Խորհուրդ է տրվում օգտագործել մասնագիտացված մոդելի օբյեկտ, որը բացում է միայն այն հատկությունները, որոնք կապված են ֆորմայի ուղարկման հետ: Օրինակ, օգտատիրոջ էլեկտրոնային հասցեն փոփոխելու ֆորմայում, մոդելի օբյեկտը պետք է հայտարարի հատկությունների նվազագույն հավաքածու, ինչպես ցույց է տրված հետևյալ ChangeEmailForm օրինակով:

public class ChangeEmailForm {
    private String oldEmailAddress;
    private String newEmailAddress;
    public void setOldEmailAddress(String oldEmailAddress) {
        this.oldEmailAddress = oldEmailAddress;
    }
    public String getOldEmailAddress() {
        return this.oldEmailAddress;
    }
    public void setNewEmailAddress(String newEmailAddress) {
        this.newEmailAddress = newEmailAddress;
    }
    public String getNewEmailAddress() {
        return this.newEmailAddress;
    }
}

Եթե դուք չեք կարող կամ չեք ուզում օգտագործել մասնագիտացված մոդելի օբյեկտ յուրաքանչյուր օգտագործման դեպքի համար, ապա դուքպետք է սահմանափակեք տվյալների կցման համար թույլատրելի հատկությունները: Իդեալում, դա կարող եք անել՝ գրանցելով թույլատրելի դաշտերի նախշերը setAllowedFields() մեթոդի միջոցով WebDataBinder-ում:

Օրինակ, ձեր հավելվածում թույլատրելի դաշտերի նախշերը գրանցելու համար, կարող եք իրականացնել @InitBinder անոթացիայով մեթոդ @Controller կամ @ControllerAdvice անոթացիայով կոմպոնենտում, ինչպես ցույց է տրված ներքևում.

@Controller
public class ChangeEmailController {
    @InitBinder
    void initBinder(WebDataBinder binder) {
        binder.setAllowedFields("oldEmailAddress", "newEmailAddress");
    }
    // մեթոդներ նշված @RequestMapping և այլն
}

Հավելյալ, կարող եք նաև գրանցել թույլատրելի դաշտերի նախշերը setDisallowedFields() մեթոդի օգնությամբ DataBinder-ում և նրա ենթադասերում: Սակայն նկատի ունեցեք, որ «թույլատրելի ցանկը» ավելի անվտանգ է քան «արգելքի ցանկը»: Հետևաբար, setAllowedFields() կիրառումը պետք է գերադասել setDisallowedFields()-ի կիրառմանը:

Նկատի ունեցեք, որ թույլատրելի դաշտերի նախշեր համակցման դեպքում մեծատառերը և փոքրատառերը ազդում են. մինչդեռ արգելքի նախշերի համակցման դեպքում՝ ոչ: Բացի այդ, դաշտը, որը համապատասխանում է արգելքի նախշին, չի ընդունվի, նույնիսկ եթե համապատասխանում է նաև թույլատրելի ցանկի նախշին: