作为服务器端表示层
MVC
经典框架的
Struts
,其突出表现就是在表示层页面流转方面。虽然在显示的视图层,
Struts
框架提供了一组功能强大的标签库来帮助运用。但是这组标签库还是比较复杂,例如要取得一个
Session
中的
JavaBean
,需要做两个步骤的动作。
(
1
)使用
<bean:define>
标签来定义一个目标
JavaBean
的标识,并从
Session
中取得源
JavaBean
赋给目标
JavaBean
。若该
JavaBean
本身是
String
类型,则只需要设置它的
name
属性,否则还需要设置
property
属性。
(
2
)使用
<bean:write>
标签将该
JavaBean
的变量属性显示出来。若该
JavaBean
本身是
String
类型,则只需要设置它的
name
属性,否则还需要设置
property
属性。
下面看一个示例,假设
Session
中有一个参数为“
TEST
”,其值为
String
类型的字符串“
hello
”。那么使用
Struts
框架的
<bean>
标签库的代码就应该是这样:
<bean:define id="test" name="TEST" scope="session"/>
<bean:write name="test"/>
定义一个目标
JavaBean
的标识“
test
”,然后将从
Session
中的参数“
TEST
”所取得的源
JavaBean
的实例赋给目标
JavaBean
。
<bean:write>
标签会根据
<bean:define>
标签的
id
属性设置自身的
name
属性,来获取目标
JavaBean
并显示出来。由于它们操作的是
String
类型的字符串,因此编码还算比较简单。可是,如果它们操作的是一个非
String
类型的
JavaBean
,那么编码就比较麻烦了。
如果使用的是
JSTL
,这部分的操作就十分简单了,仅仅通过
EL
表达式语言就可以完成了,转换成
EL
表达式的操作编码如下:
${sessionScope.TEST}
转换成
JSTL
,只要一句表达式就已经完成了
<bean>
标签库需要用两个标签和许多属性才能完成的工作。即使使用的是
JavaBean
中的属性,
JSTL
表达式也只需要再加个“
.
”操作符而已。
使用
JSTL
中的
EL
表达式和
JSTL
标签库中的标签,可以简化
Struts
标签库中许多标签的操作。下面就根据具体的对比来进行介绍。
Struts
的
Bean
标签库在
EL
表达式没有出现前是十分常用的,无论从
Session
、
request
、
page
或是其他作用范围(
Scope
)中取得参数、或者从标准
JavaBean
中读取变量属性都处理得得心应手。然而,在
EL
表达式出现之后,
Struts Bean
标签库的标签在操作的时候就显示出了烦琐的缺点。因此用
EL
表达式来替代
Struts Bean
标签库中的标签是一种较好的做法。
1. <bean:define>
标签和
<bean:write>
标签处理显示被
EL
表达式替换
q
原形:
<bean:define>
标签的作用是定义一个
JavaBean
类型的变量,从
Scope
源位置得到该
JavaBean
的实例。
<bean:write>
标签可以通过
JavaBean
变量来做显示的工作。
q
替换方案:利用
EL
表达式来替换。
q
示例比较
<bean:define>
标签和
<bean:write>
标签的动作:
<bean:define id="javaBeanName"
name="javaBeanParameter"
property="javaBeanProperty"
scope="request"/>
<bean:write name="javaBeanName"/>
EL
表达式的动作:
${requestScope.javaBeanParameter.javaBeanProperty}
或
${requestScope.javaBeanParameter['javaBeanProperty’]}
处理相同的一个动作,使用
define
标签,通常需要记住各种属性的功能,并有选择地根据实际情况来挑选是否需要
property
属性,还要指定其
scope
属性。而
EL
表达式就方便多了,直接使用默认变量
pageScope
、
requestScope
、
sessionScope
、
applicationScope
指定源
JavaBean
作用范围,利用“
.
”操作符来指定
JavaBean
的名称以及利用“
[]
”或“
.
”来指定
JavaBean
中的变量属性。
q
比较结果:无论是可读性还是程序的简洁性方面,
EL
表达式无疑要胜过许多,唯一的缺点是
EL
表达式必须使用
Servlet2.4
以上的规范。
2. <bean:cookie>
、
<bean:header>
、
<bean:parameter>
标签和
<bean:write>
标签处理显示被
EL
表达式替换
q
原形:
<bean:cookie>
、
<bean:header>
、
<bean:parameter>
标签的作用是,定义一个
JavaBean
类型的变量,从
cookie
、
request header
、
request parameter
中得到该
JavaBean
实例。
<bean:write>
标签可以通过
JavaBean
变量来做显示的工作。
q
替换方案:利用
EL
表达式来替换。
q
示例比较:
<bean:parameter>
标签的动作:
<bean:parameter id="requestString" name="requestParameterString" />
<bean:write name="requestString"/>
EL
表达式的动作:
${param.requestParameterString}
q
比较结果:
EL
表达式默认的
5
个变量:
cookie
、
header
、
headerValues
、
paramValues
、
param
完全可以提供更方便简洁的操作。
3. <bean:include>
标签被
<c:import>
标签替换
q
原形:
<bean:include>
标签的作用是定义一个
String
类型的变量,可以包含一个页面、一个响应或一个链接。
q
替换方案:利用
<c:import>
标签来替换。
q
示例比较
<bean:include>
标签的动作:
<bean:include page="/MyHtml.html" id="thisurlPage" />
<c:import>
标签的动作:
<c:import url="/MyHtml.html" var="thisurlPage" />
<bean:include>
标签的
page
属性所起的作用可以由
<c:import>
标签来替换,二者的操作结果是一样的。
q
比较结果:这一对标签的比较没有明显区别,而
<bean:include>
标签有更多属性提供更多功能,因此替换并不是十分必要。
尤其是当要用到配置在
struts-config.xml
中的
<global-forwards>
元素进行全局转发页面时,必须使用
<bean:include>
标签的
forward
元素来实现。
4. <bean:message>
标签处理资源配置文件被
<fmt:bundle>
、
<fmt:setBundle>
、
<fmt:message>
标签合作替换
q
原形:
<bean:message>
标签是专门用来处理资源配置文件显示的,而它的资源配置文件被配置在
struts-config.xml
的
<message-resources>
元素中。
q
替换方案:利用
<fmt:bundle>
、
<fmt:setBundle>
、
<fmt:message>
标签合作来替换,由
<fmt:bundle>
、
<fmt:setBundle>
设置资源配置文件的实体名称,再由
<fmt:message>
标签负责读取显示。
q
示例
比较
<bean:message>
标签的动作:
<bean:message key="message.attacksolution"/>
<fmt:bundle>
、
<fmt:message>
标签的动作:
<fmt:bundle basename="resources.application">
<fmt:message key="message.attacksolution" />
</fmt:bundle>
或
<fmt:setBundle>
、
<fmt:message>
标签的动作:
<fmt:setBundle basename="resources.application" var="resourceaApplication"/>
<fmt:message key="message.attacksolution" bundle="${resourceaApplication}"/>
q
比较结果:这一对标签对于国际化的支持都相当好,唯一最大的区别在于利用
<bean:message>
标签所操作的资源配置文件是配置在
struts-config.xml
中的,而
<fmt:message>
标签所操作的资源配置文件则是根据
<fmt:bundle>
、
<fmt:setBundle>
两组标签来得到的。看起来,后者的灵活性不错,但就笔者的眼光来看,前者更为规范,对于用户协作的要求也更高。试想,维护一到两个资源配置文件与维护一大堆资源配置文件哪个更方便呢?自然是前者了,因此除非是不依赖
Struts
框架的应用,否则最好使用
<bean:message>
标签。
Struts Logic
标签库中的标签在页面显示时是时常被用到的,但是常用的却不一定是最好用的,有了
JSTL
标签库和
EL
表达式后,许多
Struts Logic
标签库的标签可以被简单替换。
1.
所有判断标签被
EL
表达式和
<c:if>
标签替换
q
原形:判断标签有一个特点,就是需要取得一个实例的变量,因此通过
<bean:define>
标签来取得实例的变量是必须的,随后就通过各种判断标签来完成判断的工作。常用的判断标签如表
9.30
所示:
表
9.30
常用判断标签
标签名
|
描述
|
empty
|
判断变量是否为空
|
notEmpty
|
与
empty
标签正好相反
|
equal
|
判断变量是否与指定的相同
|
notEqual
|
与
equal
标签正好相反
|
lessThan
|
判断变量是否比指定的小
|
greaterThan
|
判断变量是否比指定的大
|
lessEqual
|
判断变量是否小于等于指定的值
|
greaterEqual
|
判断变量是否大于等于指定的值
|
present
|
检查
header
、
request parameter
、
cookie
、
JavaBean
或
JavaBean propertie
不存在或等于
null
的时候,判断成功
|
notPresent
|
与
present
标签正好相反
|
match
|
比较
String
类型字符串是否与指定的相同
|
notMatch
|
与
match
标签正好相反
|
q
替换方案:利用
EL
表达式和
<c:if>
标签来替换。
q
示例比较:判断标签的动作:
<bean:define id="javaBeanName"
name="javaBeanParameter"
property="attack_event_code"
scope="request"/>
<logic:notEmpty name="javaBeanParameter">
javaBeanParameter not empty
</logic:notEmpty>
EL
表达式和
<c:if>
标签的动作:
<c:if test="${requestScope.javaBeanParameter.attack_event_code != null
&& requestScope.javaBeanParameter.attack_event_code != ''”}>
javaBeanParameter not empty
</c:if>
EL
表达式利用操作符来完成判断动作,然后通过
<c:if>
标签来根据判断结果处理对应工作。
q
比较结果:
EL
表达式的操作符对判断的贡献很大,
EL
表达式的灵活性是
Struts
判断标签无法比拟的,任何判断标签都可以通过表达式来实现。
<c:if>
标签还可以将判断的结果保存为一个变量,随时为之后的页面处理服务。
反观
Struts
框架的判断标签,在工作之前必须先定义被判断的变量,而判断后又无法保存判断结果,这样的程序设计远不如
EL
表达式和
<c:if>
标签的协作来得强大。因此使用
EL
表达式和
<c:if>
标签来替换判断标签是更好的选择。
2. <logic:iterate>
标签被
<c:forEach>
标签和
EL
表达式替换
q
原形:
<logic:iterate>
标签用来对集合对象的迭代,可以依次从该集合中取得所需要的对象。
q
替换方案:利用
<c:forEach>
标签和
EL
表达式的协作替换
<logic:iterate>
标签。
q
示例比较
<logic:iterate>
标签的动作:
<logic:iterate name="allAttackSolution"
id="attackSolution"
type="struts.sample.cap1.sample3.entity.AttackSolution">
<bean:write property="attack_event_code" name="attackSolution"/>
<bean:write property="attack_mean" name="attackSolution"/>
<bean:write property="attack_action" name="attackSolution"/>
</logic:iterate>
<c:forEach>
标签
EL
表达式协作的动作:
<c:forEach items="${requestScope.allAttackSolution}" var="attackSolution">
${attackSolution.attack_event_code}
${attackSolution.attack_mean}
${attackSolution.attack_action}
</c:forEach>
两个动作都做的是同一件事,从
request
中得到保存的“
allAttackSolution
”参数,该参数为一个集合,集合中的对象为
struts.sample.cap1.sample3.entity.AttackSolution
类型的实例。
<logic:iterate>
标签本身可以接收集合,保存为一个变量,利用迭代子模式,使
<logic:iterate>
标签体中的
<bean:write>
标签将集合中的每个
JavaBean
显示出来。
提示:在本例中由于要显示
JavaBean
中的变量属性,因此
<bean:write>
标签还需要设置
property
属性。
替换工作的
<c:forEach>
标签则相对要方便些,
items
属性使用
EL
表达式取得集合,然后设置
var
属性作为集合中对象的变量,最后使用
EL
表达式来显示数据。
q
比较结果:
值得注意的一个地方是,
<logic:iterate>
标签必须为集合中的对象指定类型,因为标签库处理时会将集合中的对象作为
Object
类型得到,然后需要读取
type
属性定义的
Java
类为它强制转型。
而
<c:forEach>
标签则完全不用,只要符合标准
JavaBean
(为变量属性提供
get
、
set
方法)的对象都可以通过
EL
表达式来从
var
属性定义的变量中取得该
JavaBean
的变量属性。
因此
<c:forEach>
标签和
EL
表达式的方式更加简单,也更加灵活。
当然,熟悉
<logic:iterate>
标的程序设计者也可以将
<bean:write>
标签替换为
EL
表达式而仍然使用
<logic:iterate>
标签。代码可以是这样:
<logic:iterate name="allAttackSolution"
id="attackSolution"
type="struts.sample.cap1.sample3.entity.AttackSolution">
${attackSolution.attack_event_code}
${attackSolution.attack_mean}
${attackSolution.attack_action}
</logic:iterate>
结果一样,但这种方式比
<bean:write>
标签显示方式灵活多了。
3. <logic:redirect>
标签被
<c:redirect>
和
<c:param>
标签替换
q
原形:
<logic:redirect>
标签用来转发到一个页面,并可以为转发传递参数。
q
替换方案:利用
<c:redirect>
和
<c:param>
标签的协作替换
<logic:redirect>
标签。
q
示例比较:
<logic:iterate>
标签的动作:
<%
HashMap paramMap = new HashMap();
paramMap.put("userName", "RW");
paramMap.put("passWord", "123456");
%>
<logic:redirect page="/MyHtml.jsp" name="paramMap" scope="request" />
<c:redirect>
和
<c:param>
标签协作的动作:
<c:redirect url="/MyHtml.jsp">
<c:param name="userName" value="RW"/>
<c:param name="passWord" value="123456"/>
</c:redirect>
两个动作都做的是同一件事,都将转发到当前
Web Context
下的“
MyHtml.jsp
”去,而且都将为它提供两个参数。最后的转发链接看起来应该如下所示:
http://localhost:8080/test/ MyHtml.jsp? userName=RW&password=123456
q
比较结果
一眼就可以看出,
<logic:redirect>
标签的可读性不强,它的
name
属性表示的是一个
Map
类型的变量。如果还有
property
属性,则
name
属性指的是一个标准
JavaBean
。
property
属性指的是
JavaBean
中的一个
Map
类型的变量属性,通过
Map
的“名值对”来为转发页面传递参数。如果转发参数是来自于一个
Map
或
JavaBean
中的
Map
类型变量属性,那还好,因为可以在
Java
类中处理。可是如果纯粹是从页面上取得某些值作为转发参数,那就困难了,必须像本示例所给出的那样,自行定义一个
Map
实例。这种情况下,页面就会看到
Java
语言的片段,既麻烦又不符合标准。
而使用
<c:redirect>
和
<c:param>
标签协作,由于包含在
<c:redirect>
标签体内的
<c:param>
标签可以有多个,因此显式地提供
<c:param>
标签就完成了给出转发参数的工作,即使用到
JavaBean
,也可以使用
EL
表达式来实现。
综上所述,利用
<c:redirect>
和
<c:param>
标签来代替
<logic:redirect>
标签是有必要的。
Struts
框架和
JSTL
并不是互相冲突的两种技术,虽然
Struts
框架提供了功能不错的标签库,但是使用
JSTL
可以简化
Struts
框架标签库复杂的地方,这对于服务器端表示层框架的
Struts
来说帮助很大。
Struts
的
HTML
标签库无法使用
JSTL
来替换,但是,使用
EL
表达式作为一些
value
属性,来做赋值的工作仍然不失为一种好的选择。因此,在
JSTL
已经比较成熟的今天,使用
Struts
框架和
JSTL
整合来作
JSP
页面将使程序设计更为轻松。