基于struts2实现ajax的2种标准方法

基于struts2，有2种标准方法实现ajax

共同的一点是，Action都需要将一个方法暴露出来，给前端javascript调用

javascript的代码都是一样的：

function testAjax() {

	var $userNameInput = $("#ajax_username");
	var userName = $userNameInput.val();

	$.ajax({
		url : "originAjax.action",
		type : "GET",
		data : "ajaxField=" + userName,
		success : function(data, textStatus) {
			alert(data);
		}
	});
}

这里originAjax.action，就是暴露出来供调用的地址

下面分别介绍服务端的两种写法

第一种是原生的写法，不需要依赖插件，也没有自行解析和拼装json串的功能

Action：

public void originAjax() throws IOException {
		HttpServletResponse response = ServletActionContext.getResponse();
		PrintWriter writer = response.getWriter();
		writer.print("hello " + ajaxField);
		writer.flush();
		writer.close();
	}

struts.xml：

<action name="originAjax" class="bookAction" method="originAjax" />

以上可以看到，写法是比较麻烦的。需要在Action里通过ServletActionContext的静态方法，获取到PrintWriter，然后直接写入响应

这里的originAjax()方法的返回值类型是void，然后在struts.xml里，不需要配置<result>元素

这种写法主要有2个缺陷，首先是与Servlet组件耦合，这在struts2应用里是不推荐的做法。其次是这个Action没有办法自动从请求中将json串解析为java的域，同样，如果需要将json串写入响应的话，也需要自行编码

另一个办法，是使用struts2-json-plugin，将jar包拷贝入WEB-INF/lib就可以了
Action：

public String pluginAjax() {
		ajaxField = "hello " + ajaxField;
		return SUCCESS;
	}

struts.xml：

<package name="bookManage" extends="json-default" namespace="/book">
	
		<action name="pluginAjax" class="bookAction" method="pluginAjax">
			<result type="json">
				<param name="excludeNullProperties">true</param>
			</result>
		</action>
		
	</package>

以上可以看到，Action里的写法变得非常简单，不过要注意的是，这个方法的返回值必须是String，而不是void

在struts.xml中的配置，包要继承自json-default，然后resultType是json。这里还附加了一个参数excludeNullProperties，目的是不序列化Action里为null的字段。<result>元素没有name属性，也没有跳转值

这里面其实还有一些规则，比如说没有getter方法的字段不会被序列化，注解为@Transient的字段不会被序列化等，另外param也不止excludeNullProperties一种。本文就不详细介绍了，可以看另外一篇博客：http://unmi.cc/struts2-json-plugin-guide，或者直接看官方的文档

此外，因为这种响应ajax请求的方法，是需要放在json-default包里的，而一般的方法，只需要放在struts-default包里。但是由于业务组织的原因，很可能一个Action里，有些方法是响应ajax请求的方法，另一些方法是响应普通请求的方法。

那么这种情况下，有一种方式，是将一个Action里的不同方法，放到不同的package里，不过这样好不好我还没有结论。另外一种方式，我感觉可以把所有的package都声明成extends json-default，经过试验，对普通的方法倒是没有造成影响，不过就是不知道会不会有什么隐藏的问题

最后补充一点，json和ajax不是一回事。ajax只是一种异步请求的机制，刚才的pluginAjax.action和originAjax.action，同样是可以响应普通的请求的



这样访问也没什么不可以，只是不太实用，相当于把Action当做加强版的Servlet来用了

json只是一种数据格式，在同步请求中用json来交换数据，也是一种很常见的做法，并不一定用在ajax里

所以struts2-json-plugin作为一个插件，是补充了struts2不能原生支持json的不足，将json格式作为数据交换的格式，这个设计是很合理的。

但是struts2自身对ajax的支持就太不好了，比如我想在Action的一个方法里，直接输出一段普通文本来响应ajax请求，居然还要通过HttpServletResponse来做。我开始还不相信，在struts-default.xml里找到一个resultType，叫plainText，我以为就是这个了，想当然认为会有这种写法：

public String plainText() {
		return "my reponse for ajax";
	}

<action name="plainText" class="bookAction" method="plainText">
	<result type="plainText" />
</action>

我以为会有这样一种用法，来简单地提供对ajax的支持，结果发现plainText和我想的根本就不是一个东西，这是不是struts2一个设计不足的地方呢？

你提到的插件方法也是不错，但我并不觉得第一种方法不好，相反我觉得第一种更灵活。
比如你要返回的json数据比较复杂，用第二种方法我觉得反倒不灵活。

1、获取writer并且输出的方法可以做成工具方法。
2、应用
import net.sf.json.JSONArray;
import net.sf.json.JSONObject;
这两个类

JSONArray array = new JSONArray();
			for (Shop shop : lstShop) {
				JSONObject obj = new JSONObject();
				obj.put("id", shop.getShopId());
				obj.put("name", shop.getName());
				obj.put("address", shop.getAddress());
				obj.put("lon", shop.getLon());
				obj.put("lat", shop.getLat());
				obj.put("contactPhone", shop.getContactPhone());
				obj.put("deliverPhone", shop.getDeliverPhone());
				obj.put("canDeliver", shop.getCanDeliver());
                                   //其他层次json属性设置
                                          //省略
				array.add(obj);
			}
Util.write(response,array.toString());

   
    

我同意你的说法

有时候我也更喜欢第一种方法，但是我在struts2里没有找到一个合适的resultType，来支持把这种方法写得更简洁一点

用静态方法去获取Response，我觉得不是很对劲，如果有一种directResponse之类的resultType就好了

至于要自己写JSON，我同意你的说法，不是什么问题

我觉得两种方法多不错，各有各的优点，也有自己的不足。。

我通常的做法是前台需要的数据丢map里面去，action只返回一个Map类型的属性。

普通返回值返回字符串的情况我选择的是第一中方案。把servlet write抽离成方法直接调用。当要返回大量数据对象的时候，第二种肯定比较方便。

个人感觉都还可以吧。

我建议在一个project里别用两种方案，不利于代码维护和管控。

针对“基于struts2支持ajax”这个场景，2个方案是互补的

第一种方式，主要是没有办法自动请求的json串绑定到Action的字段里，需要对获取HttpServletRequest对象再处理

第二种方式，当响应比较复杂的时候，又不够灵活

所以同时采用2个方案是有道理的

用多种方案是根据场景来设置的。我个人感觉没有问题。假如一个项目中第二种场景里我只用了第一个方案，会增加额外的代码跟复杂度。对于将来是不利于维护的。