为什么我们不应该同时使用jspViewResolver和TilesViewResolver?
我用Tiles项目创建了Spring MVC。为什么我们不应该同时使用jspViewResolver和TilesViewResolver?
我的控制器返回一个字符串“hello”,这是一个逻辑文件名,我把jsp称为hello.jsp。
在tiles.xml中,我应该有一个名为hello的定义扩展定义模板。 我的基本定义被映射到layout.jsp。
当我添加jspViewResolver时,它将我带到hello.jsp,但是如果我将其注释掉,它将根据tile.xml中的hello定义呈现layout.jsp。
那么,为什么我们不应该同时使用jspViewResolver和tilesViewResolver?
无论是TilesViewResolver
和InternalResourceViewResolver
或UrlBasedViewResolver
的实例实例。一般而言,这意味着ViewResolver
接受给定的视图名称,并尝试从中构建一个URL,不管视图的实际存在如何,都使用此URL来解析视图。
根据Spring版本(Spring> = 3.0)和使用的子类进行检查以检查视图的实际存在。 (见this解决了问题)。
唯一的实现不是实际检查视图的存在(目前)它是InternalResourceViewResolver
还是普通的UrlBasedViewResolver
实例。当使用这个时,这使得这是视图解析器链中的最后一个(最高order
属性)。
如果您想将普通JSP与Tiles结合起来,实际上应该可以通过给TilesViewResolver
命令1和InternalResourceViewResolver
命令高于1(例如2)来实现。
在早期版本(Spring < 3.0)中,这些检查不到位,排序也没有任何影响。
两者都是UrlBasedViewResolver的实例,它简单地构造一个URL,而不管请求的视图是否存在。其他'ViewResolver'像'BeanNameViewResolver'不存在时不返回视图。在你的视图解析器链中有多个UrlBasedViewResolver会使最后一个永远不会调用。正如课程的文档中所解释的那样。 – 2014-09-22 05:41:00
如果您想将此作为答案,我可能选择此作为最佳答案。 :) – user3705478 2014-09-22 07:34:34
该评论实际上并不完全正确,给了一些更详细的解释。 – 2014-09-22 09:21:44