无法弄清楚如何创建这个if语句(Cannot figure out how to create this if statement)

 视图解析器的合约指定视图解析器可以返回null以指示无法找到视图。 但是，并非所有视图解析器都这样做，因为在某些情况下，解析器根本无法检测视图是否存在。 例如，InternalResourceViewResolver在内部使用RequestDispatcher，并且调度是确定JSP是否存在的唯一方法，但此操作只能执行一次。 VelocityViewResolver和其他一些同样适用。 检查特定视图解析程序的javadoc，以查看它是否报告不存在的视图。 因此，将一个InternalResourceViewResolver放在链中的最后一个位置会导致链未被完全检查，因为InternalResourceViewResolver将始终返回一个视图！ 
 
 重定向到视图 
 
 
 
 如前所述，控制器通常返回逻辑视图名称，视图解析器将其解析为特定的视图技术。 对于通过Servlet或JSP引擎处理的JSP等视图技术，此解决方案通常通过InternalResourceViewResolver和InternalResourceView的组合来处理，InternalResolver和InternalResourceView通过Servlet API的RequestDispatcher.forward（..）方法或RequestDispatcher发出内部转发或包含。 .include（）方法。 对于其他视图技术，例如Velocity，XSLT等，视图本身将内容直接写入响应流。 
 
 
 RedirectView的 
 
 
 
 作为控制器响应的结果，强制重定向的一种方法是控制器创建并返回Spring的RedirectView实例。 在这种情况下，DispatcherServlet不使用普通的视图解析机制。 而是因为它已经被赋予（重定向）视图，DispatcherServlet只是指示视图执行其工作。 RedirectView依次调用HttpServletResponse.sendRedirect（）将HTTP重定向发送到客户端浏览器。 
 
 
 如果您使用RedirectView并且视图是由控制器本身创建的，则建议您将重定向URL配置为注入控制器，以便它不会被烘焙到控制器中，而是在上下文中与视图名称一起配置。 名为“重定向：前缀”的部分有助于此解耦。 
 
 重定向：前缀 
 
 
 
 虽然RedirectView的使用工作正常，但如果控制器本身创建RedirectView，则无法避免控制器意识到重定向正在发生的事实。 这实际上并不是最理想的，而且会把事情过于紧密。 控制器不应该真正关心如何处理响应。 通常，它应该仅根据已注入其中的视图名称进行操作。 
 
 
 特殊的重定向：前缀允许您完成此操作。 如果返回的视图名称具有前缀redirect：，则UrlBasedViewResolver（以及所有子类）会将此识别为需要重定向的特殊指示。 视图名称的其余部分将被视为重定向URL。 
 
 净效果与控制器返回RedirectView的效果相同，但现在控制器本身可以简单地按照逻辑视图名称进行操作。 逻辑视图名称（例如redirect：/ myapp / some / resource）将相对于当前Servlet上下文重定向，而重定向等名称： http ： //myhost.com/some/arbitrary/path将重定向到绝对URL。 
 
 转发：前缀 
 
 
 
 对于最终由UrlBasedViewResolver和子类解析的视图名称，也可以使用特殊的forward：前缀。 这会创建一个InternalResourceView（最终会对视图名称的其余部分执行RequestDispatcher.forward（）），该视图名称被视为URL。 因此，此前缀对于InternalResourceViewResolver和InternalResourceView（例如，对于JSP）没有用。 但是，当您主要使用其他视图技术时，前缀可能会有所帮助，但仍希望强制Servlet / JSP引擎处理资源的转发。 （请注意，您也可以链接多个视图解析器。） 
 
 
 与redirect：前缀一样，如果将带有forward：前缀的视图名称注入控制器，则控制器不会检测到在处理响应方面发生了什么特殊情况。 
 
 
 DOCS： https ： //docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html 

The contract of a view resolver specifies that a view resolver can return null to indicate the view could not be found. Not all view resolvers do this, however, because in some cases, the resolver simply cannot detect whether or not the view exists. For example, the InternalResourceViewResolver uses the RequestDispatcher internally, and dispatching is the only way to figure out if a JSP exists, but this action can only execute once. The same holds for the VelocityViewResolver and some others. Check the javadocs of the specific view resolver to see whether it reports non-existing views. Thus, putting an InternalResourceViewResolver in the chain in a place other than the last results in the chain not being fully inspected, because the InternalResourceViewResolver will always return a view!
 
Redirecting to Views
 
 
 
As mentioned previously, a controller typically returns a logical view name, which a view resolver resolves to a particular view technology. For view technologies such as JSPs that are processed through the Servlet or JSP engine, this resolution is usually handled through the combination of InternalResourceViewResolver and InternalResourceView, which issues an internal forward or include via the Servlet API’s RequestDispatcher.forward(..) method or RequestDispatcher.include() method. For other view technologies, such as Velocity, XSLT, and so on, the view itself writes the content directly to the response stream.
 
 
RedirectView
 
 
 
One way to force a redirect as the result of a controller response is for the controller to create and return an instance of Spring’s RedirectView. In this case, DispatcherServlet does not use the normal view resolution mechanism. Rather because it has been given the (redirect) view already, the DispatcherServlet simply instructs the view to do its work. The RedirectView in turn calls HttpServletResponse.sendRedirect() to send an HTTP redirect to the client browser.
 
 
If you use RedirectView and the view is created by the controller itself, it is recommended that you configure the redirect URL to be injected into the controller so that it is not baked into the controller but configured in the context along with the view names. The the section called “The redirect: prefix” facilitates this decoupling.
 
The redirect: prefix
 
 
 
While the use of RedirectView works fine, if the controller itself creates the RedirectView, there is no avoiding the fact that the controller is aware that a redirection is happening. This is really suboptimal and couples things too tightly. The controller should not really care about how the response gets handled. In general it should operate only in terms of view names that have been injected into it.
 
 
The special redirect: prefix allows you to accomplish this. If a view name is returned that has the prefix redirect:, the UrlBasedViewResolver (and all subclasses) will recognize this as a special indication that a redirect is needed. The rest of the view name will be treated as the redirect URL.
 
The net effect is the same as if the controller had returned a RedirectView, but now the controller itself can simply operate in terms of logical view names. A logical view name such as redirect:/myapp/some/resource will redirect relative to the current Servlet context, while a name such as redirect:http://myhost.com/some/arbitrary/path will redirect to an absolute URL.
 
The forward: prefix
 
 
 
It is also possible to use a special forward: prefix for view names that are ultimately resolved by UrlBasedViewResolver and subclasses. This creates an InternalResourceView (which ultimately does a RequestDispatcher.forward()) around the rest of the view name, which is considered a URL. Therefore, this prefix is not useful with InternalResourceViewResolver and InternalResourceView (for JSPs for example). But the prefix can be helpful when you are primarily using another view technology, but still want to force a forward of a resource to be handled by the Servlet/JSP engine. (Note that you may also chain multiple view resolvers, instead.)
 
 
As with the redirect: prefix, if the view name with the forward: prefix is injected into the controller, the controller does not detect that anything special is happening in terms of handling the response.
 
 
DOCS: https://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html