struts2 通配符的配置方式
2015-07-15 17:19
417 查看
本人最近学习struts2,发现struts2 通配符的配置方式简直碉堡了。记录下来大家一起学习。
1、第一种配置方式
新建一包:com.cqxs.action
新建一个Action类:UserAction,代码如下:
public class UserAction extends ActionSupport{
public Stringadd(){
return SUCCESS;//继承自ActionSupport,这里可直接使用它的参数SUCCESS
}
}
编写配置文件:
<action name="user" class="com.cqxs.action.UserAction" method="add">
<result>/User_add_success.jsp</result>
</action>
index.jsp页面:
< a href=”user!add”>添加帐号</a>
注意:由上可知,如果此时我们的UserAction里面有100个方法,那么很自然的我们将会在sturts.xml中配置100个<action name=”” class=”” method=””/>的配置,大量的配置会花去我们很多的时间,所以能否简化该配置呢?
2、第二种配置方式:
此时仍然采用上面的包和Action类,配置文件如下:
<action name="User*" class="com.cqxs.action.UserAction" method="*">
<result>/{1}success.jsp</result>
</action>
注意:仔细查看该配置文件,你是否发现(*表示所有),此时如果UserAction里面有100个方法,那么我们只需要配置一次就足够了,所以相对于第一种配置方式,在一个大型的项目开发中,我们理所当然的节约了大量的时间,但此时新的问题又出现了,如果我们有100个甚至更多的Action类,那么麻烦又来了,我们仍然得花大量的时间在配置上。
3、第三种配置方式:
此时仍然采用上面的包和Action类,配置如下:
<action name="*_*" class="com.cqxs.action.{1}Action" method="{2}"> <result>/{1}_{2}_success.jsp</result>
</action>
注意:此时我们再来看该配置文件,是否解决了我们上面两种配置的弊端呢?答案是肯定的啦!此时如果我们再新建一个PersonAction,里面仍然有大量的方法,代码如下:
package com.cqxs.action;
import com.opensymphony.xwork2.ActionSupport;
public class PersonAction extends ActionSupport{
public Stringadd(){
return SUCCESS;
}
public String delete(){
return SUCCESS;
}
public Stringupdate(){
return SUCCESS;
}
public Stringfind(){
return SUCCESS;
}
}
注意:此时我们发现,我们的配置文件却没有做任何的改动,仍然采用的是当前的配置文件。
注意:故在项目开发之前,约定规则的好与否,对项目开发的效率有很大的影响,即约定优于配置。
1、第一种配置方式
新建一包:com.cqxs.action
新建一个Action类:UserAction,代码如下:
public class UserAction extends ActionSupport{
public Stringadd(){
return SUCCESS;//继承自ActionSupport,这里可直接使用它的参数SUCCESS
}
}
编写配置文件:
<action name="user" class="com.cqxs.action.UserAction" method="add">
<result>/User_add_success.jsp</result>
</action>
index.jsp页面:
< a href=”user!add”>添加帐号</a>
注意:由上可知,如果此时我们的UserAction里面有100个方法,那么很自然的我们将会在sturts.xml中配置100个<action name=”” class=”” method=””/>的配置,大量的配置会花去我们很多的时间,所以能否简化该配置呢?
2、第二种配置方式:
此时仍然采用上面的包和Action类,配置文件如下:
<action name="User*" class="com.cqxs.action.UserAction" method="*">
<result>/{1}success.jsp</result>
</action>
注意:仔细查看该配置文件,你是否发现(*表示所有),此时如果UserAction里面有100个方法,那么我们只需要配置一次就足够了,所以相对于第一种配置方式,在一个大型的项目开发中,我们理所当然的节约了大量的时间,但此时新的问题又出现了,如果我们有100个甚至更多的Action类,那么麻烦又来了,我们仍然得花大量的时间在配置上。
3、第三种配置方式:
此时仍然采用上面的包和Action类,配置如下:
<action name="*_*" class="com.cqxs.action.{1}Action" method="{2}"> <result>/{1}_{2}_success.jsp</result>
</action>
注意:此时我们再来看该配置文件,是否解决了我们上面两种配置的弊端呢?答案是肯定的啦!此时如果我们再新建一个PersonAction,里面仍然有大量的方法,代码如下:
package com.cqxs.action;
import com.opensymphony.xwork2.ActionSupport;
public class PersonAction extends ActionSupport{
public Stringadd(){
return SUCCESS;
}
public String delete(){
return SUCCESS;
}
public Stringupdate(){
return SUCCESS;
}
public Stringfind(){
return SUCCESS;
}
}
注意:此时我们发现,我们的配置文件却没有做任何的改动,仍然采用的是当前的配置文件。
注意:故在项目开发之前,约定规则的好与否,对项目开发的效率有很大的影响,即约定优于配置。
相关文章推荐
- Java中的重载、重写、多态,静态绑定、动态绑定
- eclipse 添加注释简介
- java-泛型返回值的方法类型
- java Runtime.exec() 执行问题
- java web每天定时执行任务
- java 命令参数知识
- java的线程通信
- JAVA常用类总结
- 解决Struts中文乱码问题总结
- MyEclipse快捷键大全
- eclipse 设置系统变量和运行参数
- Java中Runnable和Thread的区别
- 解决struts2过滤器冲突的简单方法
- eclipse clean up与formatter的区别
- eclipse Package, Source folder, folder认识
- 简述上转型对象和接口回调
- Java ArrayList、Vector、LinkedList 异同
- java写的控制台万年历
- java汉字转拼音
- spring annotation注解@Component 通用:@Controller,@ Service,@ Repository区别