Page History

...

The model repository is designed to be used for the typical edit/save use case that many web applications must handle. The use case begins with the use user choosing to edit an object in the system. The system loads the given object from the database and displays the object for the user to edit. At the same time, the object should be stored in the session so it can be retrieved later. Once the user is finished editing the object, the user clicks the save button and the page is submited back to the application. At this point, the object is restored from the session and the new values are applied to the newly restored object. Then the object is persisted to the database, so the new values are not lost.

...

Now simply annotate your domain model with an @In and @Out session annotation using the string constant from above as the session key.:

public class ExampleAction extends ActionSupport {

	@In(scope = ScopeType.SESSION, value = ModelRepo.DOMAIN_MODEL)
	@Out(scope = ScopeType.SESSION, value = ModelRepo.DOMAIN_MODEL)
	private ExampleBean exampleBean;

	...

	public String edit() {
		...
		return SUCCESS;
	}

	public String save() {
		...
		return SUCCESS;
	}
}

That's all. After the edit, the domain model will be stored in the session. On the save, the model will be restored before the new values are applied.

Model Repository vs. params-prepare-params

An alternative to the model repository is to use the params-prepare-params interceptor stack. The params-prepare-params interceptor stack requires the object you are editing to be re-read from the database. In cases where optimistic locking is used, this completely circumvents the version field. In these cases, the originally read object should be used when saving the object.