Spring MVC View Parser

The view parser provided by Spring MVC uses Viewresolver for view parsing to implement a rendering model in the browser. Viewresolver can parse multiple views such as JSPs, velocity templates, freemarker templates, and XSLT.
The two most important interfaces of the spring processing view are viewresolver and view. The Viewresolver interface provides a mapping between the view name and the true view, while the view interface processes the request to render the real view to the user.

1. Viewresolver View Parser

In the spring MVC controller, all the request processing methods (actions) must parse out a logical view name, either explicitly (return String,view or Modelandview) or implicitly (based on the contract, such as the view name is the method name). The views in spring MVC are handled by the view resolver with this logical view name, and spring commonly uses the following view parsers:
　　 1.1) Abstractcachingviewresolver: The abstract view parser used to cache the view. Typically, the view is ready before it is used. Inherit the parser to be able to use the view cache. This is an abstract class, the view parser will cache its once parsed view, and then every time to parse the view from the cache to find, if the corresponding view is found directly back, if not create a new View object, and then put it in a cache for the map, The new view is then returned. Using this view caching method minimizes the performance problems of the resolution view.
　　 1.2) Xmlviewresolver: XML view parser. It implements the Viewresolver interface, which accepts XML configuration files of the same DTD definition as the Spring XML Bean factory. It inherits from the Abstractcachingviewresolver abstract class, so it is also supported for view caching. In layman's terms, the relationship between a logical name and a real view is specified through XML.
　　 1.3) Resourcebundleviewresolver: It uses the bean under the ResourceBundle definition, implements the Viewresolver interface, and specifies the name of the binding package. Typically, the configuration file is defined in the properties file under Classpath, and the default file name is Views.properties.
　　 1.4) Urlbasedviewresolver: it simply implements the Viewresolver interface, which does not have to be explicitly defined and directly affects the mapping of the logical view to the URL. It allows you to access resources through the logical view name without any mapping. It is a simple implementation of the Viewresolver, and inherited the Abstractcachingviewresolver, mainly provides a way of stitching URLs to parse the view, it allows us to specify a specified prefix through the prefix property, Specifies a specified suffix through the suffix property, and then adds the returned logical view name with the specified prefix and suffix to the specified view URL. Redirect: prefix indicates redirection, ForWord: prefix indicates forwarding.
　　 1.5) Internalresourceviewresolver: Internal View resolver. It is a subclass of Urlbasedviewresolver, so the features supported by Urlbasedviewresolver are supported.
　　 1.6) Velocityviewresolver: Velocity view parser, Urlbasedviewresolver subclass, Velocityviewresolver parses the returned logical view to Velocityview.
　　 1.7) Freemarkerviewresolver: Freemarker view parser, urlbasedviewresolver subclass, freemarkerviewresolver resolves the logical view returned by the controller processing method to Freemarkerview, When using Freemarkerviewresolver, we do not need to specify their viewclass, because Viewclass has been freemarkerview in Freemarkerviewresolver. Spring itself supports the integration of Freemarker. You only need to configure a view resolver for Freemarker.
　　 1.8) Contentnegotiatingviewresolver: Content Negotiation View resolver, which allows you to use the same content data to render different views available in RESTful services. The contentnegotiatingviewresolver itself does not parse the view, it simply determines which parser to use based on the information requested. Generally it has two mechanisms: suffix name, accept header.

<bean class= "Org.springframework.web.servlet.view.ContentNegotiatingViewResolver" > <property name= " MediaTypes "> <map> <entry key=" Atom "value=" Application/atom+xml "/> <entry key=" HTML "value  = "text/html"/> <entry key= "json" value= "Application/json"/> </map> </property> <property Name= "Viewresolvers" > <list> <bean class= "Org.springframework.web.servlet.view.BeanNameViewResolver"/ > <bean class= "org.springframework.web.servlet.view.InternalResourceViewResolver" > <property name= "prefix" value= "/web-inf/jsp/"/> <property name= "suffix" value= ". jsp"/> </bean> </list&gt  ; </property> <property name= "Defaultviews" > <list> <bean class= "ORG.SPRINGFRAMEWORK.WEB.SERVL Et.view.json.MappingJackson2JsonView "/> </list> </property></bean><bean id=" Content "class = "Com.springsource.samples.rest.SamplEcontentatomview "/> 

2, about the view resolution chain
Spring supports the simultaneous configuration of multiple view parsers, the chained view parser. This way, in some cases, you can override some views. If we configure multiple view resolvers and want to sort the view parser, setting the Order property allows you to specify the sequence in which the parser executes. The higher the order value, the later the parser executes, and when a viewresolver is null for the view object returned after the resolution is parsed, it means that the viewresolver cannot resolve the view. At this point, if there are other viewresolver that have a greater order value than that, the view will be resolved by calling the one with the lowest order value in the remaining Viewresolver, and so on. Internalresourceviewresolver this resolves all views, that is, the viewresolver that can always return a non-empty view object must be placed on the last side of the Viewresolver chain.

3. About REDIRECT Redirection
At some point, you need to use redirection. Spring provides a redirectview that allows the controller to return an instance of this class, in which case Dispatcherservlet does not use the usual view resolution mechanism. Redirectview calls the Httpservletresponse.sendredirect () method.
3.1) Redirect: prefix
The processor method returns the redirect: prefix in such a way that the processor only needs to deal with the view parser, without needing to care whether it needs to be redirected or rendered directly, that is, the controller does not know that the redirection occurs at all.
　　3.2) Forward: prefix
Use the name of the view with the forward: prefix, which is parsed correctly by Urlbasedviewresolver and its subclasses. The internal implementation of parsing is to generate a internalresourceview, which will eventually call the Requestdispatcher.forward () method, which will take the remainder of the forward View name as a URL. So, when using Internalresourceviewresolver/internalresourceview and the view technology you're using is a JSP, you don't need to use this prefix. However, this forward prefix is useful when you are primarily using other view technologies, but you still need to force forward on pages that servlet/jsp engine handles.

Reference: http://www.cnblogs.com/best/p/5670509.html

Https://blog.zenfery.cc/archives/131.html?replytocom=14

Spring MVC View Parser