View Resolution

See equivalent in the Reactive stack

Spring MVC는 특정 view technology에 종속되지 않고 browser에서 model을 rendering할 수 있도록 해주는 ViewResolver 및 View 인터페이스를 정의합니다. ViewResolver는 view 이름과 실제 view 간의 매핑을 제공합니다. View는 특정 view technology에 넘기기 전에 data를 준비하는 부분을 다룹니다.

다음 table은 ViewResolver hierarchy에 대한 더 자세한 내용을 제공합니다:

ViewResolver	Description
AbstractCachingViewResolver	AbstractCachingViewResolver의 subclass들은 resolve하는 view instance를 cache합니다.<br>Caching은 특정 view technology의 성능을 향상시킵니다. cache property를 false로 설정하여<br>cache를 끌 수 있습니다. 또한 runtime에 특정 view를 refresh해야 하는 경우(예: FreeMarker template이 수정된 경우),<br>removeFromCache(String viewName, Locale loc) 메서드를 사용할 수 있습니다.
UrlBasedViewResolver	명시적인 mapping 정의 없이 논리적 view 이름을 URL로 직접<br>resolve하는 ViewResolver 인터페이스의 간단한 구현입니다.<br>이는 논리적 이름이 임의의 mapping 필요 없이<br>간단한 방식으로 view resource의 이름과 일치하는 경우에 적합합니다.
InternalResourceViewResolver	InternalResourceView(실질적으로 Servlet 및 JSP)와 JstlView와 같은<br>subclass를 지원하는 UrlBasedViewResolver의 편의 subclass입니다. setViewClass(..)를 사용하여<br>이 resolver에 의해 생성되는 모든 view에 대해 view class를 지정할 수 있습니다.<br>자세한 내용은 UrlBasedViewResolver<br>javadoc을 참조하십시오.
FreeMarkerViewResolver	FreeMarkerView 및 그 custom subclass를 지원하는 UrlBasedViewResolver의 편의 subclass입니다.
ContentNegotiatingViewResolver	요청 file 이름 또는 Accept header를 기반으로 view를 resolve하는<br>ViewResolver 인터페이스의 구현입니다. Content Negotiation을 참조하십시오.
BeanNameViewResolver	view 이름을 현재 애플리케이션 context의 bean 이름으로 해석하는<br>ViewResolver 인터페이스의 구현입니다. 이는 서로 다른 view 이름에 따라<br>다양한 view type을 혼합하여 사용할 수 있는 매우 유연한 variant입니다.<br>각각의 View는 예를 들어 XML이나 설정 class에서 bean으로 정의할 수 있습니다.

Table 1. ViewResolver implementations

Handling

See equivalent in the Reactive stack

하나 이상의 resolver bean을 선언하고 필요하다면 order property를 설정하여 순서를 지정함으로써 view resolver를 chain할 수 있습니다. order property가 높을수록 view resolver는 chain에서 더 나중에 위치하게 됩니다.

ViewResolver의 contract는 view를 찾을 수 없음을 나타내기 위해 null을 반환할 수 있음을 명시합니다. 그러나 JSP 및 InternalResourceViewResolver의 경우 JSP가 존재하는지 알아내는 유일한 방법은 RequestDispatcher를 통해 dispatch를 수행하는 것입니다. 따라서 전체 view resolver 순서에서 항상 InternalResourceViewResolver를 마지막에 구성해야 합니다.

view resolution을 구성하는 것은 Spring 설정에 ViewResolver bean을 추가하는 것만큼 간단합니다. MVC Config는 View Resolvers와 controller logic 없이 HTML template rendering에 유용한 logic-less View Controllers를 추가하기 위한 전용 설정 API를 제공합니다.

Redirecting

See equivalent in the Reactive stack

view 이름에 있는 특별한 redirect: prefix를 사용하면 redirect를 수행할 수 있습니다. UrlBasedViewResolver(및 그 subclass)는 이를 redirect가 필요하다는 지시로 인식합니다. view 이름의 나머지 부분은 redirect URL입니다.

net effect는 controller가 RedirectView를 반환한 것과 동일하지만, 이제 controller 자체는 논리적 view 이름 관점에서 동작할 수 있습니다. (redirect:/myapp/some/resource와 같은) 논리적 view 이름은 현재 Servlet context를 기준으로 redirect하며, redirect:https://myhost.com/some/arbitrary/path와 같은 이름은 절대 URL로 redirect합니다.

Forwarding

view 이름에 대해 UrlBasedViewResolver 및 subclass에 의해 최종적으로 resolve되는 특별한 forward: prefix도 사용할 수 있습니다. 이는 RequestDispatcher.forward()를 수행하는 InternalResourceView를 생성합니다. 따라서 이 prefix는 InternalResourceViewResolver 및 InternalResourceView(JSP의 경우)와 함께 사용할 때는 유용하지 않지만, 다른 view technology를 사용하면서도 Servlet/JSP engine에 의해 처리될 resource의 forward를 강제하고자 할 때는 도움이 될 수 있습니다. 대신 여러 view resolver를 chain할 수도 있다는 점에 유의하십시오.

Content Negotiation

See equivalent in the Reactive stack

ContentNegotiatingViewResolver는 view를 직접 resolve하지 않고 다른 view resolver에 위임한 뒤, client가 요청한 representation과 유사한 view를 선택합니다. representation은 Accept header나 query parameter(예: "/path?format=pdf")에서 결정될 수 있습니다.

ContentNegotiatingViewResolver는 요청 media type을 각 ViewResolver에 연관된 View가 지원하는 media type(Content-Type이라고도 함)과 비교하여 요청을 처리할 적절한 View를 선택합니다. list에서 호환 가능한 Content-Type을 가진 첫 번째 View가 client에 대한 representation을 반환합니다. ViewResolver chain에서 호환 가능한 view를 제공할 수 없는 경우, DefaultViews property를 통해 지정된 view list가 참조됩니다. 후자의 option은 논리적 view 이름에 관계없이 현재 resource의 적절한 representation을 rendering할 수 있는 singleton View에 적합합니다. Accept header에는(text/*와 같은) wildcard가 포함될 수 있으며, 이 경우 Content-Type이 text/xml인 View는 호환 가능한 match가 됩니다.

구성에 대한 자세한 내용은 MVC Config 아래의 View Resolvers를 참조하십시오.