crystal reports barcode font THE VIEW LAYER in Font

Generation PDF-417 2d barcode in Font THE VIEW LAYER

can be prioritized if they implement the Ordered interface and this is what some of the concrete ViewResolvers do. Set the order bean property on the resolver to control chaining order, as demonstrated in Listing 7-12. Listing 7-12. Ordering View Resolvers <bean id="defaultViewResolver" 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> <!-- this will be consulted first as it has a lower 'order' value --> <bean id="pdfViewResolver" class="org.springframework.web.servlet.view.XmlViewResolver"> <property name="order" value="1"/> <property name="location" value="/WEB-INF/views.xml"/> </bean>

Caution A lower value for the order property gives it a higher priority in the chain. Values for the order

Chaining works in the following manner. Each ViewResolver in turn, according to its ordered property, gets the option of returning a view. If the resolver returns null, the next resolver in the chain is consulted. If a resolver returns a view instance, the dispatcher uses that view, and no further calls are made to other resolvers that might still be in the chain. View resolution ends at the first successful attempt to resolve a view name. Bear in mind, however, that not all ViewResolvers can return null even though the contract of the interface permits it. In particular, InternalResourceViewResolver never returns null because its implementation depends on calling the RequestDispatcher internally. There s no other way to discover whether a JSP exists, and the RequestDispatcher.forward() method can only be called once. This means that your ViewResolver will always return a view of some description, and this particular resolver should only ever appear last in the chain. Practically, that means that your application can return 404 errors where you don t want them, so it s always important to configure a generic page to handle this type of error.

Note This section is naturally about views, but we ve left it until after the discussion on ViewResolvers

Sometimes you don t want a view to be rendered as part of a single request-response transaction from the client. This usually applies to form data that is POSTed to a Controller where the correct response might be to delegate to another Controller. When you do this internally, the delegate Controller has access to all of the form POST data, which may not be desirable. In addition, the user can double-post the form data by reloading the current page in the browser after submitting the form. Both of these problems can be overcome by having the Controller that receives the form POST issue a redirect to the client, shown in Figure 7-6. This causes the browser to make a new request the URL in the address bar to change too. Now if the user hits the Reload button, she ll get the page that was the subject of the redirect and won t inadvertently submit a new set of form POST details something that could involve a credit card purchase. The problem and its Redirect after POST solution are commonly understood, so let s take a look at how to deal with this in Spring MVC applications.

: client : [POST form data]

: render() response.sendRedirect() or response.setStatus(303) HTTP 302 / 303 : [GET successUrl] : handleRequest() : ModelAndView

: render()

Figure 7-6. Redirect after POST Spring provides a RedirectView class which implements the View interface but under the covers simply sets the response headers to force the client to re-request its configured URL. If you re using ResourceBundleViewResolver or XmlViewResolver, you can define RedirectViews as you would any other view. If, however, you ve chosen to use an UrlBasedViewResolver or one of its subclasses, then the nature of the resolver makes it impossible to specify a redirect simply by using a logical key as the view name.