在SimpleFormController中用“SessionForm”概念构建修改信息页面

在通常的修改信息页面中都会先显示一张表单包含原有信息，用户修改原有信息表单然后提交完成信息的修改。

通过继承SimpleFormController复写部分方法来实现这一功能：
第一： 复写“protected ModelAndView showForm(HttpServletRequest request, HttpServletResponse response, BindException errors, Map controlModel) ”方法。
该方法用于显示包含原有信息的表单，在该方法中实现如下功能：

1. 提取Command对象事例。 Spring Framework在调用该方法前已经创建了配置文件中所指定的Command对象，可以通过“errors.getBindingResult().getTarget()”来获取Command对象
2. 提取被修改信息的ID，该ID信息可以通过页面上下文放在URL query string中。
3. 调用对应的Service方法根据ID获取原始数据信息并加入到Command对象中。
4. 将Command对象加入到session中“session.setAttribute(cmdNameInSession, cmd);”， 该session变量的名称需要通过AbstractFormController的“getFormSessionAttributeName (HttpServletRequest request)”方法获得。
5. 设置AbstractFormController的“setSessionForm(true)”将该FormController设置为 SessionForm，这样在用户修改完Form信息再次提交时Spring Framework不会再创建一个新的Command对象，而是从Session中取出上一次保存在session中的command对象并将用户新提交 的值付给原有的Command对象。在AbstractFromController的“protected final Object getCommand(HttpServletRequest request)”方法中可以看到如上所述的逻辑
   

第二：复写doSubmitAction方法。 在该方法中调用对应的Service来完成数据的修改。

在这里有一个SessionForm的概念，通过Session来传递Command对象，用户修改表单并提交后，保存在Session中的 Command对象也会被修改，这样只要从Session中获取修改后的Command对象并交由对应的Service就可以完成数据的修改工作。类似与 “AbstractWizardFormController”中一页页传递Command对象的做法。

Spring Framework是在什么时候修改Session中的这个Command对象的还需要进一步研究。

我的理解有点小小的不同。

第一：显示原有信息

override protected Object formBackingObject(HttpServletRequest request)

从url中取得id，调用service取得原有信息，返回。

第二：修改信息

override protected void doSubmitAction(Object command)

这一步好像和你的理解一样。

我不知道command的信息是否放在session里，但是至少在继承的程序里没有体现。

是的，覆写formBackingObject方法就是利用Session Form。使用Session Form还必须将Form设置为Session Form。如下代码末端用红色序号标注的地方表示了通过formBackingObject在“GET"修改页面时将Command Object加入到Session的过程。用绿色序号标注的代码表示了如何在”POST“请求后从Session中取出Command对象。

此段代码拷贝自Spring的AbstractFormController类。



如此看来覆写formBackingObject方法才是使用Session Form的正道。不过就是好像必须在form初始化时手动设置为Session Form。
现在还没有看出来Session中的Command对象是什么时候被修改的，这还是个问题。

sessionForm的默认值是false，在我的FormController中也没有设为true，所以目前我的FormController应该没有用sessionForm。
而且，正常情况下，如果没有必要，还是不用session的好。

不好意思，一下发了俩个，还不能删除。没有灌水的意思。

如果在你的代码中没有设置SessionForm为True的话，在POST请求过来时，“getCommand”会再次调用“formBackingObject”来创建新的Object，如果在你覆写的“formBackingObject”方法中包含了数据库查询操作的话，就以位置会再次查询数据库然后返回一个新的Command对象，之后在Spring Framework中回把表单中提交的信息设置到Command对象中。结果就是和设置SessionForm一样，但不同只出就是需要再次查询数据库。

所以如果不用Session，又不想额外的查询数据库的话最好在覆写的“formBackingObject”中根据request的类型来决定是否需要再次查询数据库代码类似于：

protected Object formBackingObject(HttpServletRequest request) throws Exception {
	if (isFormSubmission(request)) {
		//1. Return saved command object
	}
	else {
		//1. Query Database
		//2. Save result to Command object
	}
}

可以具体说明使用Session为什么不好吗？


现在大概知道Command对象是如何被修改的了：

protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response)
		throws Exception {

	// Form submission or new form to show?
	if (isFormSubmission(request)) {
		// Fetch form object from HTTP session, bind, validate, process submission.
		try {
			Object command = getCommand(request);
			ServletRequestDataBinder binder = bindAndValidate(request, command);
			BindException errors = new BindException(binder.getBindingResult());
			return processFormSubmission(request, response, command, errors);
		}
		catch (HttpSessionRequiredException ex) {
			// Cannot submit a session form if no form object is in the session.
			if (logger.isDebugEnabled()) {
				logger.debug("Invalid submit detected: " + ex.getMessage());
			}
			return handleInvalidSubmit(request, response);
		}
	}

	else {
		// New form to show: render form view.
		return showNewForm(request, response);
	}
}

如上述代码，在调用完"getCommand"后我们得到了Command对象（该Command对象可能是新建的也可能是从session中取出的），接下来会调用“bindAndValidate”，就是在这个bind and validate过程中将Form中提交的数据更新到Command对象中。

我觉得额外的数据库查询是需要的，当你更新一条记录的时候，form表单里可能没有所有的字段，所以对于这些字段，应该保留原有值。另外，和其他表的关系可能也不在表单里。所以修改记录时，先取出原来的值，然后和用户的输入合并（bind），可能是比较好的办法。



我的理解是：
如果同一个人同时用这个FormController不止一次（譬如同时打开多个tab），由于session的属性名字是一样的，从一个tab切换到另一个tab就会出现冲突。

而且session是全局的，估计会占用系统资源，session多了之后，可能增加调试的难度。如果你不小心在request中设置同样的属性，我记得session的属性优先，也就是说你在页面拿不到request的值。

仅供参考。

嗯，这个和取出原始数据的方式有关系。我是将被修改对象的所有相关数据都取出来的，所以有些个别字段是用户不可修改的比如表的ID，关联表的ID等等，但是这些数据又是在修改数据时所必须的。所以我的最初想法就是在取出数据后需要有个地方保留这些完整的原始数据对象，在表单提交后更新这些原始的数据对象，最后更新到数据库中。这种做法的好处是不需要两次查询数据库，不过如果有多个人同时更新同一个表的同一条记录，是会出现脏数据的问题。

所幸的是，当前我考虑的应用修改的是个人数据，就是说登录用户自己的数据，逻辑上不允许出现多人个人同时修改同一条记录。



喔，如果用户开了两个窗口他们记录在session中的对象是两个不同的实例，这个冲突是存在数据的写写冲突。这个冲突即便不用Session存放原始数据也会存在。

对于Session对资源的占用问题我的想法是可以将原始的完成数据保存在一个全局Cache中，以一个唯一ID作为cache entry的key，根据这个key来存取数据对象。Cache的操作流程如下：

1. 在Get请求时，生成唯一ID，将原始数据放入Cache中。
2. 将唯一ID计入Session中
3. 在POST请求时在Session中取出唯一ID
4. 删除Session中记录此唯一ID的属性
5. 根据ID取出原始数据
6. 删除Cache中的原始数据
7. 更新数据对象
8. 更新数据库

这样是把数据换成数据的ID，也就是说资源的存放位置换了个地方。

先澄清一点，我们这里是讨论HttpSession。

假设我们有一个ProductFormController，可以修改产品信息。

同一个用户可以打开多个窗口，譬如

product.form?id=1
product.form?id=2

而session的属性名是一样的，下面获得属性名的代码。clas名和command名都是一样的。

	protected String getFormSessionAttributeName() {
		return getClass().getName() + ".FORM." + getCommandName();
	}

当访问 product.form?id=1 时，session里保存的是产品1的信息，然后访问 product.form?id=2 这时，session里的信息变成了产品2，如果你切换到产品1，更新产品1，应该会出现意外结果。

另外，在 AbstractFormController 中，使用sessionForm 时，整个对象都放在session中，你没有选择。

啊～，知道你的意思了，这确是个问题。这样看来放在Session中是肯定会碰到问题的了。不过通过自定义的Cache也是可以解决数据库两次查询的问题。只是Cache中原始数据的key是不能放在session中的了，是要放在表单的某个隐藏值中待POST回来时通过他定位原始数据。



是的，我的意思是不设置SessionForm为True，直接重载formBackingObject方法，就是你提到过的方式。然后在formBackingObject方法中根据请求类型对原始数据进行Cache存取操作。

一个简单的Cache定义：

public final class SessionCommandUtil {
	private static Map<String, Object> sessionCmd = 
							new HashMap<String, Object>();
	private static long subId = 0;

	public static synchronized String addCommand(Object cmd) {
		
		String key = Long.toString(subId++);
		sessionCmd.put(key, cmd);
		if (subId == Long.MAX_VALUE)
			subId = 0;

		return key;
	}

	public static synchronized Object getCommand(String id) {
		
		return sessionCmd.get(id);
	}

}