5

I have some UI where an admin can update products. During my dev/testing, I only ever opened one window, and everything worked as it should.

Then the client was editing, and they opened multiple tabs for different products, and upon saving, this caused a duplicate field issue.

I am assuming this is a combination of @SessionAttributes and @ModelAttribute. The last product opened, is the one put in the session, so if you try edit the first tab, you will actually have the incorrect product.

Is my approach below, using SessionAttribute, and ModelAttribute incorrect?

My Controller:

@Controller
@SessionAttributes({ "product" })
public class ProductController {

@RequestMapping(value = "/product/update/{productId}", method = RequestMethod.GET)
public String update(@PathVariable Long productId, Model model) {
    Product product;
    if (productId == null) {
        product = new Product();
    } else {
        product = Product.find(productId);
    }
    model.addAttribute("product", product);
    return "product/update";
}

@RequestMapping(value = "/product/update", method = RequestMethod.POST)
public String update(@ModelAttribute Product product, BindingResult result,
        Model model) {
    if (result.hasErrors()) {
        return "product/update";
    }
    product = product.merge();
    return "redirect:/product/update/" + product.getId();
}

}

Vijay Shanker Dubey
  • 4,308
  • 6
  • 32
  • 49
kabal
  • 2,085
  • 4
  • 29
  • 43
  • You should use `request` scope instead of `session` scope to allow a user to do multiple tasks within its session. – Rubens Mariuzzo May 29 '12 at 13:52
  • Hi, I found this solution, and I thought it my help you. http://mandeep312.blogspot.com/2014/05/when-you-are-using-sessionattributes.html#more – Dan Torrey Jan 29 '15 at 13:21

2 Answers2

2

In cases where you will just show the object stored in Session and will not allow it being edited or replaced, this approach is okay. But for cases like this, it is advisable to use request scope rather than session scope.

Logan
  • 2,445
  • 4
  • 36
  • 56
  • would this then require my form to have have hidden fields for all the fields I dont want to edit? e.g. the ID – kabal May 29 '12 at 14:10
  • this is then probably a case where I need to make a command specific object, that "wraps" my domain object, as there are lots of fields/composition that will never be edited by users, that I dont want to have to now make hidden fields – kabal May 29 '12 at 14:54
  • It is not necessary to make the non-editable fields as hidden. You can show them on UI (if needed), in non-editable forms, like by just using the EL rather them putting them inside any editable component. – Logan May 30 '12 at 02:05
  • Also, if you don't want to show these fields, then just don't use the EL to show them. This way they will automatically be hidden, hence no need to make them hidden explicitly. – Logan May 30 '12 at 02:06
2

I ended up using a custom SessionAttributeStore, based on the article by Marty Jones

http://marty-java-dev.blogspot.com/2010/09/spring-3-session-level-model-attributes.html

kabal
  • 2,085
  • 4
  • 29
  • 43