Розпізнавання подання

Spring MVC визначає інтерфейси ViewResolver та View, які дозволяють візуалізувати моделі в браузері, не прив'язуючи тебе до конкретної технології подання. ViewResolver забезпечує зіставлення між іменами подання та реальним поданням. View займається підготовкою даних перед передачею до конкретної технології подання.

У цій таблиці міститься докладніша інформація про ієрархію ViewResolver:

Обробка

Ти можеш створювати ланцюжки розпізнавачів подання, оголошуючи більше одного біна розпізнавача і, в разі необхідності, встановлюючи властивість order для визначення порядку. Пам'ятай, що чим вища властивість порядку, тим пізніше в ланцюжку розташовується розпізнавач подання.

Контракт ViewResolver визначає, що він може повертати null, щоб визначити, що подання не може бути знайдено. Однак у випадку з JSP і InternalResourceViewResolver єдиний спосіб з'ясувати, чи існує JSP, це виконати диспетчеризацію через RequestDispatcher. Тому завжди потрібно розташовувати InternalResourceViewResolver у конфігурації останніх у загальному порядку розпізнавачів подання.

Конфігурувати розпізнавання подання так само просто, як додати біни ViewResolver до конфігурації Spring. MVC Config надає спеціальний конфігураційний API для розпізнавачів подання та додавання контролерів подання без алгоритму, які корисні для візуалізації HTML-шаблону без алгоритму управління.

Переадресація

Спеціальний префікс redirect: на ім'я подання дозволяє виконати переадресацію. UrlBasedViewResolver (і його підкласи) розпізнає це як команду здійснити необхідну переадресацію. Решта імені подання — це URL-адреса переадресації.

Кінцевий результат такий самий, як контролер повертав RedirectView, але тепер сам контролер може працювати з іменами логічного подання. Ім'я логічного подання (наприклад, redirect:/myapp/some/resource) здійснює переадресацію щодо поточного контексту сервлета, тоді як ім'я, таке як redirect:https://myhost.com/some/arbitrary/path, здійснює переадресацію на абсолютну URL-адресу.

Зверни увагу, що якщо метод контролера анотовано @ResponseStatus, значення анотації має пріоритет над статусом відповіді, встановленим RedirectView.

Перенаправлення

Ти також можеш використовувати спеціальний префікс forward: для імен подання, що зрештою розпізнється UrlBasedViewResolver та підкласами. Це створює InternalResourceView, який виконує RequestDispatcher.forward(). Тому цей префікс марний при використанні InternalResourceViewResolver і InternalResourceView (для JSP), але він може виявитися корисним, якщо використовується інша технологія подання, але все ж таки необхідно у примусовому порядку перенаправити ресурс на обробку контейнером сервлетів/JSP. Зверни увагу, що натомість також можна зв'язати в ланцюжок кілька розпізнавачів подання.

Узгодження вмісту

ContentNegotiatingViewResolver не розпізнає подання самостійно, а делегує цю роботу іншим розпізнавателям і здійснює вибірку подання, яке схоже на те, на яке клієнт зробив запит. Подання може бути визначене із заголовка Accept або параметра запиту (наприклад, "/path?format=pdf").

ContentNegotiatingViewResolver обирає відповідний View для обробки запиту шляхом порівняння типів даних запиту з типом даних (також відомим як Content-Type), що підтримується View, пов'язаний з кожним з його ViewResolvers. Перший View у списку, який має сумісний Content-Type, повертає подання клієнту. Якщо ланцюжку ViewResolver не вдається надати сумісне подання, використовується список подання, зазначений у властивості DefaultViews. Цей останній варіант підходить для одиночних Views, які можуть візуалізувати відповідне подання поточного ресурсу незалежно від імені логічного подання. Заголовок Accept може містити знаки підстановки (наприклад, text/*), у цьому випадку View, чиє Content-Type дорівнює text/xml, є сумісним.