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

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

Таблиця 3. Реалізації ViewResolver
ViewResolver Опис

AbstractCachingViewResolver

Підкласи AbstractCachingViewResolver кешують екземпляри подання, які вони розпізнають. Кешування підвищує продуктивність певних технологій подання. Можна вимкнути кеш, встановивши властивість cache у false. До того ж, якщо тобі необхідно оновити певне подання під час виконання програми (наприклад, у разі зміни шаблону FreeMarker), можна використовувати метод removeFromCache(String viewName, Locale loc).

UrlBasedViewResolver

Проста реалізація інтерфейсу ViewResolver, яка забезпечує пряму роздільну здатність логічних імен подання до URL-адреси без явного визначення відображення. Це доречно, якщо логічні імена збігаються з іменами ресурсів подання у простій формі без необхідності довільного зіставлення.

InternalResourceViewResolver

Зручний підклас UrlBasedViewResolver, який підтримує InternalResourceView (по суті, сервлети та JSP) та підкласи, такі як JstlView та TilesView . Можна зазначити клас подання для кожного подання, що створюється цим розпізнавачем, використовуючи setViewClass(..). Подробиці див. у javadoc UrlBasedViewResolver.

FreeMarkerViewResolver

Зручний підклас UrlBasedViewResolver, який підтримує FreeMarkerView та їх підкласи користувача.

ContentNegotiatingViewResolver

Реалізація інтерфейсу ViewResolver, який розпізнає подання на основі імені файлу запиту або заголовка Accept.

BeanNameViewResolver

Реалізація інтерфейсу ViewResolver, який інтерпретує ім'я подання як ім'я біна в контексті програми. Це дуже гнучкий варіант, який дозволяє змішувати та зіставляти різні типи подання на основі різних імен подання. Кожна така реалізація View може бути визначена як бін, наприклад, у XML-класах або конфігураційних класах.
Вебінар JavaRush

Обробка

Ти можеш створювати ланцюжки розпізнавачів подання, оголошуючи більше одного біна розпізнавача і, в разі необхідності, встановлюючи властивість 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, є сумісним.