在Spring MVC中链接URL视图解析器

从标准Ja​​va EE转发到内部资源的方法如下：

publicclassMyServletextendsHttpServlet{

  publicvoiddoGet(HttpServletRequestreq,HttpServletResponseresp){
    req.getRequestDispatcher("/WEB-INF/page/my.jsp").forward(req,resp);
  }
}

诚然，即使没有JSP位置，servlet代码和视图技术之间也没有脱钩。

Spring MVC引入了ViewResolver的概念。 控制器只处理逻辑名，逻辑名和实际资源之间的映射由ViewResolver处理。 更好的是，控制器完全独立于解析器：只需在Spring上下文中注册后者就足够了。

这是一个非常基本的控制器，请注意没有关于最终资源位置的提示。

@Controller
publicclassMyController{

  @RequestMapping("/logical")
  publicStringdisplayLogicalResource(){
    return"my";
  }
}

更好的是，这里没有关于资源性质的任何信息。 它可以是JSP，HTML，Tiles，Excel工作表等。 每个都有基于专用 ViewResolver的定位策略。 最常用的解析器是InternalResourceViewResolver ; 它的意思是在大多数情况下将JSP转发给内部资源。 初始化如下：

@Bean
  publicViewResolverpageViewResolver(){
    InternalResourceViewResolverresolver=newInternalResourceViewResolver();
    resolver.setPrefix("/WEB-INF/page/");
    resolver.setSuffix(".jsp");
  returnresolver;
}

鉴于此视图解析器在Spring上下文中可用，逻辑名称"my"将尝试使用"/WEB-INF/page/my.jsp"路径进行解析。 如果资源存在，可以，否则，Spring MVC将返回404。

现在，如果我的JSP使用不同的文件夹怎么办？ 我希望能够配置两个不同的视图解析器，一个具有特定的前缀，另一个具有不同的前缀。 我还希望对它们进行确定的检查，并将其从第一个退到最后一个。 Spring MVC提供了多个具有确定性顺序的解析器，但需要注意的是：它不适用于InternalResourceViewResolver ！

引用Spring MVC Javadoc：

链接ViewResolvers时，一个InternalResourceViewResolver总是需要最后一个，因为它将尝试解析任何视图名称，而不管基础资源是否实际存在。

这意味着我无法在我的上下文中配置两个InternalResourceViewResolver ，或更确切地说，我可以配置两个，但是第一个将终止查找过程。 背后的原因（以及实际代码）是，解析程序在配置有资源路径的RequestDispatcher上获取句柄。 只有在很久以后才将调度程序转发到，发现它不存在。

对我来说，这是不可接受的，因为我的用例很普遍。 此外，仅配置"/WEB-INF"作为前缀并返回路径的其余部分（ "/page/my" ）是不可能的，因为这最终使将逻辑名与资源位置解耦的目的不复存在。 最糟糕的是，我已经看到如下控制器代码来解决此限制：

returngetViews().get("my");// The controller has a Map view property with "my" as key and the complete path as the "value"

我认为必须有更多类似于Spring的方法来实现这一目标，并且我认为ViewResolver是一种优雅的解决方案，它可以检查资源是否存在。

publicclassChainableUrlBasedViewResolverextendsUrlBasedViewResolver{

  publicChainableUrlBasedViewResolver(){
      setViewClass(InternalResourceView.class);
  }

  @Override
  protectedAbstractUrlBasedViewbuildView(StringviewName)throwsException{
    Stringurl=getPrefix()+viewName+getSuffix();
    InputStreamstream=getServletContext().getResourceAsStream(url);
    if(stream==null){
      returnnewNonExistentView();
    }
    returnsuper.buildView(viewName);
  }

  privatestaticclassNonExistentViewextendsAbstractUrlBasedView{
    @Override
    protectedbooleanisUrlRequired(){
        returnfalse;
    }

    @Override
    publicbooleancheckResource(Localelocale)throwsException{
      returnfalse;
    }

    @Override
    protectedvoidrenderMergedOutputModel(Map<String,Object>model,
                                           HttpServletRequestrequest,
                                           HttpServletResponseresponse)throwsException{
      // Purposely empty, it should never get called
    }
  }
}

我的第一次尝试是尝试在buildView()方法中返回null 。 不幸的是，稍后在代码中引发了一些NPE。 因此，该方法返回一个视图a。 告诉呼叫者基础资源不存在b。 不允许对其URL进行检查（如果未设置，URL有时也会失败）。

我对这种解决方案感到非常满意，因为它使我能够像这样配置上下文：

@Configuration
@EnableWebMvc
@ComponentScan(basePackages="ch.frankel.blog.spring.viewresolver.controller")
publicclassWebConfig{

  @Bean
  publicViewResolverpageViewResolver(){
    UrlBasedViewResolverresolver=newChainableUrlBasedViewResolver();
    resolver.setPrefix("/WEB-INF/page/");
    resolver.setSuffix(".jsp");
    resolver.setOrder(0);
    returnresolver;
  }

  @Bean
  publicViewResolverjspViewResolver(){
    InternalResourceViewResolverresolver=newInternalResourceViewResolver();
    resolver.setPrefix("/WEB-INF/jsp/");
    resolver.setSuffix(".jsp");
    resolver.setOrder(1);
    returnresolver;
  }
}

现在，我对Spring哲学非常了解：我已经完全解耦，并且正在使用Spring标称解析器排序。 唯一的缺点是，在给定不同视图解析器的情况下，通过使用指向不同资源的相同逻辑名称，一个资源可以使另一个资源蒙上阴影。 正如使用多个视图解析器的情况一样，我已经准备接受风险。

可以在此处找到IntelliJ IDEA / Maven格式的展示项目。

翻译自: https://blog.frankel.ch/chaining-url-view-resolvers-in-spring-mvc/