本人最近学习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;

    }

}

注意：此时我们发现，我们的配置文件却没有做任何的改动，仍然采用的是当前的配置文件。

 

注意：故在项目开发之前，约定规则的好与否，对项目开发的效率有很大的影响，即约定优于配置。