SimpleFormController with hibernate pojo as backing object

I really would like to know your opinions on this one:

I am doing a web application that has a form (basically an edit mask) which is filled with the properties of a hibernate pojo. This pojo has several associations to other tables, so it has a lot of lazy-loading collections on it.
What I really want to do in the edit form is edit some direct properties of this pojo - let's say the property "name".

The problem is, that I have all the primary properties of my pojo in my form, but not the associated values. If I simply save them to the database, all associations are gone since the backing object was created using only all given information in the form - and those didnt contain any collections or such.

Is there a clever pattern that you use for those cases? I mean, okay - i could always use a "command" that has only the user specific properties and then copy all the values to my *real* user, but that would feel kinda awkward, since the "Backing Object" pattern was invented to prevent doing stuff like this, wasn't it?

You're saying that the backing object was created using the properties from the form. Usually I either save the whole object in the session, re-attaching it upon form submission or (and I personally like this one better) reload the object upon formsubmission.

rgds,
Alef

I think you should use the copy scheme, because when you are validating your input form and there are errors, these errors will already have been placed inside your hibernate pojo. So when the user then presses cancel, the pojo will contain the incorrect values, but these will still be saved since hibernate now sees a changed object.

If I am completely wrong about this, I really would like to know how to solve this problem, because I dont like having struts like forms.

Gr
Ronald

@Alef Arendsen
You say, you reload the object upon form submission. How do you do that? Do you mean someting like

Code:

---

protected ModelAndView onSubmit(HttpServletRequest request, HttpServletResponse response,
            Object command, BindException errors) throws Exception {
    User u = (User)command;
    User dbUser = userManager.getById(u.getId();
    dbUser.setName = u.getName();
    userManager.save(dbUser);
}

---

Because that is what I am trying to avoid (Manually copying values back and forth). Or should I override the formBackingObject and pull the object from the database there? I think the problem with that would be the error issue that rharing already pointed out.

Maybe what I want is not even possible. I mean if I went and reattached the User in my HttpSession like suggested, I'd still had to copy some values manually, right?

I think I just found what I was looking for in the Petclinic examples. I'm still figuring out the details, but the comparison between AddPetForm and EditPetForm was very insightful.

I go and setSessionForm(true); and setBindOnNewForm(true); then i override formBackingObject and load the pojo determined by its id there. When I use my edit form everything looks fine now.

Quote:

---

Originally Posted by rharing

I think you should use the copy scheme, because when you are validating your input form and there are errors, these errors will already have been placed inside your hibernate pojo. So when the user then presses cancel, the pojo will contain the incorrect values, but these will still be saved since hibernate now sees a changed object.

---

I imagine this happens mostly from the usage of OpenSessionInViewInterceptor, combined with presentation layer validation outside the transaction. I guess either you have to not use OSIVI (which is what I do), or manually evict the pojo from the session in case of validation errors - or like you said, make a copy first.

True, I am using the openSessionInViewInterceptor (or Filter I think). You say that you don't use it, so do you create the hibernate session yourself? How did you solve this issue?

Most of the time I just live with doing them (loading the form backing object and the final biz transaction writing it back) in separate sessions. Comparing with either having to make a sandbox copy first, or having side effects, I'd rather sacrifice a bit of the performance.

I don't, like, never ever use OSIVI - only when I really could use some heavy lazy loading in view rendering. Come to think of it, I have never had a usage scenario where the user would need to submit a form and as the result is shown a complex view - there has almost always been either a "your request is successful" page in between, or a client side redirect. :)