J2EE第六周

一、Facelets

1.简介

Facelets提供了一个强有力的模板化系统，让你使用HTML样式的模板来定义JSF的表现层，减少了组件整合进表现层时候冗余的代码，而不需要一个web容器。 

 

2.模板框架

在提供针对组件构建设计的模板框架方面，Facelets 与 Tapestry 类似。但是，对于具有 JSP 背景的我们来说，Facelets 看起来比 Tapestry 友好得多。它允许使用熟悉的 JSTL 样式的标记和 JSTL/JSF/JSP 样式的表达式语言。大大降低的学习曲线意味着可以更加迅速地开始开发。

Facelets 和 TapestryFacelets 与 Tapestry 很相似，可以相互比较。实际上，Tapestry 刚出现的时候，大大领先于它的时代，而 Facelets 确实借鉴了它的一些想法。但是，如果只把 Facelets 当成 JSF 版本的 Tapestry，那就错了。这两项技术是不同的。要了解关于 Tapestry 的更多内容，请参阅 Brett McLaughlin 两部分的系列 “In tune with Tapestry”。

Facelets 允许定义能够直接包含进页面或者容易地添加到 Facelet 标记库的组件集。实际上让人高兴的是在 Facelets 中定义定制标记（复合组件和类似 JSP 定制标记的标记）的迅速。使用这些组件集，Facelets 还允许定义站点模板（和更小的模板）。这与使用 Tiles 很相似，但是少了定义文件。也可以在定制 JSF 组件内部使用 Facelets，因为 Facelets API 提供了可以容易地与 JSF 组件集成的接口。

来源：https://baike.baidu.com/item/facelets/10077801?fr=aladdin

 

二、关于JSF的生命周期

1 重建视图: 建立组件树,如果是首次渲染,则组件树被重置合适的状态;如果是首次渲染，则组件树被创建跳到响应阶段(JSF的组件树结构和DOM是一样的，只不过一个是client一个是server)。

2 应用请求值: 树中的每个组件都能从请求参数中提取的新的值，并把值存储本地.为之后的处理所有与组件相关的事件进入队列，如果某个组件的immediate属性设置为true，那么验证，转换，以及与组件关联的事件在这个阶段被处理(注意:并不是不处理).

3 处理验证: 组件值转换成与之相对应的数据类型。如果转换失败，这一阶段将继续完成所有剩余的转换器，验证和运行所需的检查，但在完成后，跳转到生命周期的Render Response阶段。

如果验证成功，则检查组件上的required 的属性。如果该属性是必须的并且组件中输入了值，那么与之相关的验证程序运行。如果required的属性是必须但又没有输入值，这一阶段完成（所有剩余验证程序还会继续执行），然后生命周期跳跃到Render Response阶段。如果required 属性标识为false,不管组件中有没有输入值，验证过程都不会运行。

在此阶段的末尾,组件的值会被重置为converted后的值，任何的validation或者conversion的错误信息及事件在FaceContext实例中排队,值修改事件开始触发。

验证顺序:converter->required->validator

总而言之，对于一个可以编辑的input组件,在Process Validations阶段遵循以下几个环节:
   a:如果converter失败,required检查和validators都不会执行
   b:如果converter成功，但是required检查失败validators不会执行
   c:如果converter和required都成功，所有的validators都会执行,在多个validators不管哪个validator失败了其余的validator都会继续执行,理由就是开发人员需要知道尽量多的 错  误提示来修改错误。

4 更新模型: 验证组件的本地值移动到模型中，同时本地副本被丢弃。

5 调用应用程序: 执行应用级逻辑（如事件处理程序。

6 呈现响应: 呈现树中的组件。后续请求和Restore View阶段保存状态信息。

来源：https://blog.csdn.net/amwiacel/article/details/14451617