Spring MVC 4 viewresolver View Parser

All our MVC frameworks have its own mechanism for parsing views, Spring MVC is no exception, it uses Viewresolver for view parsing, and lets users render the model in the browser. Viewresolver is an out-of-the-box technology that resolves multiple views of JSP, velocity templates, and XSLT.

The two most important interfaces of the spring processing view are viewresolver and view. The Viewresolver interface provides mappings between the view name and the true view, while the view interface processes the request to render the real view to the user.

1. Several common Viewresolver view parsers

In the Spring MVC 4 controller, all processing methods must return a logical view name, whether explicit (return String,view or Modelandview) or implicit. The view in spring handles this logical view name by the view parser, and spring has the following view parsers:

Abstractcachingviewresolver: An abstract view parser used to cache views. Usually, the view is ready before it is used. You can use the view cache by inheriting the parser.

Xmlviewresolver:xml View parser. It implements the Viewresolver interface and accepts an XML configuration file with the same DTD definition as the XML Bean factory for spring.

Resourcebundleviewresolver: It uses the bean under the ResourceBundle definition, implements the Viewresolver interface, and specifies the name of the bundle. Typically, the configuration file is defined in the properties file under Classpath, and the default file name is Views.properties.

Urlbasedviewresolver: It simply implements the Viewresolver interface, which does not explicitly define and directly affects the mapping of logical views to URLs. It allows you to access resources through the logical view name without any mapping.

Internalresourceviewresolver: internationalized View parser.

Velocityviewresolver/freemarkerviewresolver:velocity or Freemarker view parser.

Contentnegotiatingviewresolver: Content Negotiation View Parser

In JSP view technology, Spring MVC often uses the Urlbasedviewresolver view parser, which translates the view name into a URL and renders the view after the request is processed by RequestDispatcher.

<bean id= "Viewresolver"
class= "Org.springframework.web.servlet.view.UrlBasedViewResolver" >
<property name= "Viewclass" value= "Org.springframework.web.servlet.view.JstlView"/>
<property name= "prefix" value= "/web-inf/views/"/>
<property name= "suffix" value= ". JSP"/></bean>

If we configure the URL view parser shown above, we return a view name called "Favmvc", the view parser forwards the request to RequestDispatcher, and then jumps to the/web-inf/views/favmvc.jsp page.

If we want to use different view techniques in our applications, we should use Resourcebundleviewresolver.

<bean id= "Viewresolver"
class= "Org.springframework.web.servlet.view.ResourceBundleViewResolver" >
<property name= "basename" value= "views"/>
<property name= "Defaultparentview" value= "Parentview"/></bean>

Resourcebundleviewresolver for each view you want to work with, check the uniqueness of basename in ResourceBundle, which uses [ViewName]. (class) As the view class, [viewname].url as the URL of the view.

2. Chain View parser (chaining viewresolvers)

Spring supports the configuration of multiple view parsers at the same time, the chain view parser. This way, in some cases, some views can be overridden. If we have multiple view parsers configured and want to sort the view parser, the order attribute can be set to specify the sequence in which the parser executes. The higher the value of the order, the later the parser executes.

The example shown in the following code consists of two view parsers. Internalresourceviewresolver is always the last to execute, and xmlviewresolver specifies to parse the XML view (Internalresourceviewresolver does not support Excel view).

<bean id= "Jspviewresolver" class= "Org.springframework.web.servlet.view.InternalResourceViewResolver" >
<property name= "Viewclass" value= "Org.springframework.web.servlet.view.JstlView"/>
<property name= "prefix" value= "/web-inf/jsp/"/>
<property name= "suffix" value=. jsp "/></bean><bean id=" Excelviewresolver "class=" Org.springframework.web.servlet.view.XmlViewResolver ">
<property name= "Order" value= "1"/>
<property name= "Location" value= "/web-inf/views.xml"/></bean><!--in Views.xml--><beans>
<bean name= "The" class= "Org.springframework.example.ReportExcelView"/></beans>

If the view parser does not specify a view, spring examines the other view parser until there is a complete view parser containing the view. If a complete view parser is not found, spring throws a servletexception.

The view parser stipulates that NULL is returned if no view is found. But not all view parsers do this, because in some cases the parser does not detect the presence of a view. For example, when Internalresourceviewresolver uses requestdispatcher internally, dispatch forwarding is the only way to determine whether a JSP exists, but the action can only be performed once. Velocityviewresolver and other parsers do the same, distinguishing whether these view parsers can return null without a view, the best way is to look at the official documentation for support. Because Internalresourceviewresolver always returns to the view, using Internalresourceviewresolver in the view chain allows you to avoid these problems.

3. REDIRECT View

The way to force redirection in a controller controller is to create and return a Redirectview instance of spring. In this case, Dispatcherservlet no longer uses the normal view mechanism because it has returned a redirected view, Dispatcherservlet just tells the view to display it.

Redirectview invokes the Httpservletresponse.sendredirect () method, which is then returned to the client browser as an HTTP redirect. By default, all template property variables are considered redirected URLs, and the remaining attributes are automatically appended as query parameters.

REDIRECT Prefix

Although Redirectview works well, it is no doubt that the controller itself knows how to redirect if the controller itself creates redirectview. This is not good, the controller should not care about how the response is handled, it simply handles the injected view name.

When we return the view name, if the "redirect:" prefix (such as "redirect:/login") is used, the Urlbasedviewresolver view Controller recognizes that this is a special redirect. And the view name after redirect as the redirected address.

If we return the "Redirect:/favboy" view in the Http://favccxx.com application, the system redirects to Http://favccxx.com/favboy. But if we return to a view like "redirect:http://favsoft.me", the system redirects to the Http://favsoft.me view.

Forward prefix

</