- 向后兼容。 支持JSF 1.2涉及的工作太多，而Spring 3.1中出现了太多的好东西，可以忽略。
- MVC注释为王。
@RequestMapping似乎是大多数人的首选方法。 让我们仅支持此功能，并将所有自定义注释保持在最低限度。 - 减少依赖性。 重用东西很好，但这是一个集成项目，因此集成越少越好。
考虑到这一点，我决定以Web Flow的org.springframework.faces.mvc.JsfView类为灵感。 该类非常好用，因为它只处理MVC的View ，而Model和Controller完全保留在Spring领域中。 JsfView的唯一问题是缺少回发支持。 我们需要以某种方式检测对视图的初始请求和任何后续的JSF回发之间的差异。
由于Spring MVC具有非常灵活的架构，因此这是完全可能的。 我们可以在DispatcherServlet注册多个HandlerMapping和HandlerAdapter bean。 为了支持JSF，我们需要在此链中的某个较高层来检测和处理回发，而将不是回发的所有内容以常规方式处理。 这是事件的一般顺序：
user dispatcher @controller| /some/request | ||-------------------->| maps to || |------------->| creates| | |------------> FacesView| | (/pages/file.xhtml)| | render || |-------------------------------->|| | [Delegate to JSF]| response |<--------------------------------||<--------------------|| || || /some/request || (postback) ||-------------------->| postback handler| |--------->|| | [Delegate to JSF]| response |<---------||<--------------------| || | | 回发处理程序有几个有趣的问题要处理。 1）我们怎么知道我们是回发。 2）我们如何知道要还原的视图。 显然，回发将是HTTP POST操作，但是我们不能盲目地假设所有POST都是JSF回发。 我们还需要知道要还原的XHTML文件，但是该文件基于最后一个请求的@Controller做出的决定。
这两个问题的答案是编写我们自己的JSF ResponseStateManager 。 ResponseStateManager是JSF状态管理基础结构的一部分，并负责读取和写入组件状态。 通常，JSF会将状态数据保存在HTTP会话中，并在页面内写入一个隐藏的表单字段，以便以后可以还原。 使用这种机制，我们可以为MVC编写一个附加字段，该字段的存在使我们知道我们有一个回发，而且该值还将使我们知道要还原的XHTML文件。
有了回发处理程序，我们现在可以充分利用Spring和JSF的优势。 我们可以使用@RequestMapping批注来构建富有表现力的URL，并使用JSF组件来呈现复杂的网页。 如果愿意，我们甚至可以基于完全不同的技术为同一URL返回不同的视图（例如，通过检查HTTP标头，我们可能决定返回JSF页面或XML文档）。
如果要查看回发处理程序代码，可在此处获得 。 通常是将代码库移动的注意事项。
参考： 集成Spring和JavaServer Faces： JCG合作伙伴 Phillip Webb的 MVC 细节 在Phil Webb的Blog上 。
翻译自: https://www.javacodegeeks.com/2012/03/spring-jsf-integration-mvc-nuts-and.html
查询后求总数(count))
