第六周:Life Cycle(JSF & Facelets)

本文详细介绍了JSF(JavaServer Faces)和Facelets的生命周期,包括JSF的执行阶段与渲染阶段,以及Facelets如何创建和渲染视图。在执行阶段,JSF会恢复视图、应用请求值、验证流程、更新模型值并调用应用;在渲染阶段,视图被构建并呈现给客户端。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、Life Cycle Of  JSF 

JSF(JavaServer Faces)应用程序的生命周期从客户端对页面发出HTTP请求时开始,并在服务器响应页面时结束。

JSF生命周期分为两个主要阶段:

  • 执行阶段
  • 渲染阶段

下图为JSF生命周期的各个阶段:

 

1. 执行阶段

在执行阶段,当第一次请求时,构建或恢复应用程序视图。 对于其他后续请求,执行其他操作,如应用请求参数值,对组件值执行转换和验证,受托管的bean将使用组件值进行更新,并调用应用程序逻辑。
执行阶段被进一步分成以下子阶段。

  • 恢复视图阶段
  • 应用请求值阶段
  • 流程验证阶段
  • 更新模型值阶段
  • 调用应用阶段
  • 渲染响应阶段

恢复视图阶段

当客户端请求一个JavaServer Faces页面时,JavaServer Faces实现开始恢复视图阶段。 在此阶段,JSF将视图中的组件构建为请求页面,线性事件处理程序和验证器的视图,并将视图保存在FacesContext实例中。

如果对该页面的请求是回发,那么与该页面相对应的视图已经存在于FacesContext实例中。 在此阶段,JavaServer Faces实现通过使用保存在客户端或服务器上的状态信息来还原视图。

应用请求值阶段

在此阶段,在回发请求期间恢复组件树。 组件树是表单元素的集合。树中的每个组件通过使用其decode(processDecodes())方法从请求参数中提取其新值。 之后,该值将本地存储在每个组件上。

  • 如果任何解码方法或事件侦听器在当前FacesContext实例上调用了renderResponse方法,则JavaServer Faces实现将跳过“渲染响应”阶段。
  • 如果任何事件在此阶段已排队,则JavaServer Faces实现将事件广播到有兴趣的监听器。
  • 如果应用程序需要重定向到其他Web应用程序资源或生成不包含任何JavaServer Faces组件的响应,则可以调用FacesContext.responseComplete()方法。
  • 如果当前请求被识别为部分请求,则从FacesContext检索部分上下文,并应用部分处理方法。

流程验证阶段

在此阶段,JavaServer Faces通过使用其validate()方法来处理在组件上注册的所有验证器。 它检查指定验证规则的组件属性,并将这些规则与为组件存储的本地值进行比较。 JavaServer Faces还完成了没有将immediate属性设置为true的输入组件的转换。

  • 如果任何验证方法或事件侦听器在当前FacesContext上调用了renderResponse方法,则JavaServer Faces实现将跳过“渲染响应”阶段。
  • 如果应用程序需要重定向到不同的Web应用程序资源或生成不包含任何JavaServer Faces组件的响应,则可以调用FacesContext.responseComplete方法。
  • 如果事件在此阶段已排队,则JavaServer Faces实现将它们广播给有兴趣的监听器。
  • 如果当前请求被识别为部分请求,则从FacesContext检索部分上下文,并应用部分处理方法。

更新模型值阶段

确保数据有效后,它遍历组件树,并将相应的服务器端对象属性设置为组件的本地值。 JavaServer Faces实现只更新输入组件的value属性指向bean属性。 如果本地数据无法转换为bean属性指定的类型,生命周期将直接前进到“渲染响应”阶段,以便重新呈现页面并显示错误。

  • 如果任何updateModels方法或任何监听器在当前FacesContext实例上调用了renderResponse()方法,则JavaServer Faces实现将跳过“渲染响应”阶段。
  • 如果应用程序需要重定向到其他Web应用程序资源或生成不包含任何JavaServer Faces组件的响应,则可以调用FacesContext.responseComplete()方法。
  • 如果任何事件在此阶段已排队,JavaServer Faces实现将它们广播到有兴趣的监听器。
  • 如果当前请求被识别为部分请求,则从FacesContext检索部分上下文,并应用部分处理方法。

调用应用阶段

在此阶段,JSF处理应用程序级事件,例如提交表单或链接到另一个页面。
现在,如果应用程序需要重定向到其他Web应用程序资源或生成不包含任何JSF组件的响应,则可以调用FacesContext.responseComplete()方法。

之后,JavaServer Faces实现将控制转移到“渲染响应”阶段。

渲染响应阶段

这是JSF生命周期的最后阶段。 在此阶段,JSF将构建视图并将权限委托给相应的资源来呈现页面。

  • 如果这是初始请求,则页面上表示的组件将被添加到组件树中。
  • 如果这不是初始请求,组件已经添加到树中,不需要再添加。
  • 如果请求是回应,并且在应用请求值阶段,过程验证阶段或更新模型值阶段期间遇到错误,则在此阶段将再次呈现原始页面。

如果页面包含h:messageh:messages标签,页面上会显示任何排队的错误消息。
在渲染视图的内容之后,保存响应的状态,以便后续请求可以访问它。 恢复视图阶段可以使用保存的状态。

2. 渲染阶段

在此阶段,请求的视图作为对客户端浏览器的响应。 视图渲染是以HTML或XHTML生成输出的过程。 所以,用户可以在浏览器看到它。

在渲染过程中采取以下步骤。

  1. 当客户端对index.xhtml网页进行初始请求时,编译应用程序。
  2. 应用程序在编译后执行,并为应用程序构建一个新的组件树,并放置在FacesContext中。
  3. 使用由EL表达式表示的组件和与其关联受托管bean属性填充组件树。
  4. 基于组件树。 建立了新的视图。
  5. 该视图作为响应呈现给请求客户端。
  6. 组件树被自动销毁。
  7. 在后续请求中,重新构建组件树,并应用已保存的状态。

 

二、Life Cycle Of  Facelets 

JSF规范定义了JavaServer Faces应用程序的生命周期。以下步骤为基于 Facelets 的应用程序的过程描述。 

  1. 生命周期是在客户端使用Facelets创建的网页发出新请求时启动。 JSF创建一个新的组件树或javax.faces.component.UIViewRoot并放入FacesContex

  2. 如果可用的UIViewRoot应用于Facelets, 视图可以填充组件进行渲染。

  3. 新建的视图作为对客户端的响应而被渲染。

  4. 在渲染时,存储此视图的状态用于下一个请求。 存储输入组件和表单数据的状态。

  5. 客户端可以与视图交互,并从JSF应用程序请求另一个视图。 此时,保存的视图从存储状态恢复。

  6. 恢复视图再次通过JSF生命周期,如果没有验证问题,并且没有触发任何操作,最终将生成新视图或重新呈现当前视图。

  7. 如果请求相同的视图,则再次呈现存储的视图。

  8. 如果要求新视图,则继续执行【步骤2】。

  9. 将新视图作为对客户端的响应。

 

 

转载于:https://www.cnblogs.com/MnineJane/p/8854207.html

【基于QT的调色板】是一个使用Qt框架开发的色彩选择工具,类似于Windows操作系统中常见的颜色选取器。Qt是一个跨平台的应用程序开发框架,广泛应用于桌面、移动和嵌入式设备,支持C++和QML语言。这个调色板功能提供了横竖两种渐变模式,用户可以方便地选取所需的颜色值。 在Qt中,调色板(QPalette)是一个关键的类,用于管理应用程序的视觉样式。QPalette包含了一系列的颜色角色,如背景色、前景色、文本色、高亮色等,这些颜色可以根据用户的系统设置或应用程序的需求进行定制。通过自定义QPalette,开发者可以创建具有独特视觉风格的应用程序。 该调色板功能可能使用了QColorDialog,这是一个标准的Qt对话框,允许用户选择颜色。QColorDialog提供了一种简单的方式来获取用户的颜色选择,通常包括一个调色板界面,用户可以通过滑动或点击来选择RGB、HSV或其他色彩模型中的颜色。 横渐变取色可能通过QGradient实现,QGradient允许开发者创建线性或径向的色彩渐变。线性渐变(QLinearGradient)沿直线从一个点到另一个点过渡颜色,而径向渐变(QRadialGradient)则以圆心为中心向外扩散颜色。在调色板中,用户可能可以通过滑动条或鼠标拖动来改变渐变的位置,从而选取不同位置的颜色。 竖渐变取色则可能是通过调整QGradient的方向来实现的,将原本水平的渐变方向改为垂直。这种设计可以提供另一种方式来探索颜色空间,使得选取颜色更为直观和便捷。 在【colorpanelhsb】这个文件名中,我们可以推测这是与HSB(色相、饱和度、亮度)色彩模型相关的代码或资源。HSB模型是另一种常见且直观的颜色表示方式,与RGB或CMYK模型不同,它以人的感知为基础,更容易理解。在这个调色板中,用户可能可以通过调整H、S、B三个参数来选取所需的颜色。 基于QT的调色板是一个利用Qt框架和其提供的色彩管理工具,如QPalette、QColorDialog、QGradient等,构建的交互式颜色选择组件。它不仅提供了横竖渐变的色彩选取方式,还可能支持HSB色彩模型,使得用户在开发图形用户界面时能更加灵活和精准地控制色彩。
标题基于Spring Boot的二手物品交易网站系统研究AI更换标题第1章引言阐述基于Spring Boot开发二手物品交易网站的研究背景、意义、现状及本文方法与创新点。1.1研究背景与意义介绍二手物品交易的市场需求和Spring Boot技术的适用性。1.2国内外研究现状概述当前二手物品交易网站的发展现状和趋势。1.3论文方法与创新点说明本文采用的研究方法和在系统设计中的创新之处。第2章相关理论与技术介绍开发二手物品交易网站所涉及的相关理论和关键技术。2.1Spring Boot框架解释Spring Boot的核心概念和主要特性。2.2数据库技术讨论适用的数据库技术及其在系统中的角色。2.3前端技术阐述与后端配合的前端技术及其在系统中的应用。第3章系统需求分析详细分析二手物品交易网站系统的功能需求和性能需求。3.1功能需求列举系统应实现的主要功能模块。3.2性能需求明确系统应满足的性能指标和安全性要求。第4章系统设计与实现具体描述基于Spring Boot的二手物品交易网站系统的设计和实现过程。4.1系统架构设计给出系统的整体架构设计和各模块间的交互方式。4.2数据库设计详细阐述数据库的结构设计和数据操作流程。4.3界面设计与实现介绍系统的界面设计和用户交互的实现细节。第5章系统测试与优化说明对系统进行测试的方法和性能优化的措施。5.1测试方法与步骤测试环境的搭建、测试数据的准备及测试流程。5.2测试结果分析对测试结果进行详细分析,验证系统是否满足需求。5.3性能优化措施提出针对系统性能瓶颈的优化建议和实施方案。第6章结论与展望总结研究成果,并展望未来可能的研究方向和改进空间。6.1研究结论概括本文基于Spring Boot开发二手物品交易网站的主要发现和成果。6.2展望与改进讨论未来可能的系统改进方向和新的功能拓展。
1. 用户与权限管理模块 角色管理: 学生:查看个人住宿信息、提交报修申请、查看卫生检查结果、请假外出登记 宿管人员:分配宿舍床位、处理报修申请、记录卫生检查结果、登记晚归情况 管理员:维护楼栋与房间信息、管理用户账号、统计住宿数据、发布宿舍通知 用户操作: 登录认证:对接学校统一身份认证(模拟实现,用学号 / 工号作为账号),支持密码重置 信息管理:学生完善个人信息(院系、专业、联系电话),管理员维护所有用户信息 权限控制:不同角色仅可见对应功能(如学生无法修改床位分配信息) 2. 宿舍信息管理模块 楼栋与房间管理: 楼栋信息:名称(如 "1 号宿舍楼")、层数、性别限制(男 / 女 / 混合)、管理员(宿管) 房间信息:房间号(如 "101")、户型(4 人间 / 6 人间)、床位数量、已住人数、可用状态 设施信息:记录房间内设施(如空调、热水器、桌椅)的配置与完好状态 床位管理: 床位编号:为每个床位设置唯一编号(如 "101-1" 表示 101 房间 1 号床) 状态标记:标记床位为 "空闲 / 已分配 / 维修中",支持批量查询空闲床位 历史记录:保存床位的分配变更记录(如从学生 A 调换到学生 B 的时间与原因) 3. 住宿分配与调整模块 住宿分配: 新生分配:管理员导入新生名单后,宿管可按专业集中、性别匹配等规则批量分配床位 手动分配:针对转专业、复学学生,宿管手动指定空闲床位并记录分配时间 分配结果公示:学生登录后可查看自己的宿舍信息(楼栋、房间号、床位号、室友列表) 调整管理: 调宿申请:学生提交调宿原因(如室友矛盾、身体原因),选择意向宿舍(需有空位) 审批流程:宿管审核申请,通过后执行床位调换,更新双方住宿信息 换宿记录:保存调宿历史(申请人、原床位、新床位、审批人、时间) 4. 报修与安全管理模块 报修管理: 报修提交:学生选择宿舍、设施类型(如 "
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值