Hi Haiko, Thanks for the response. You raise some good points - it certainly would be cleaner and easier to understand. It also could be better for my layout, given the way I've organized the code: The data layer is abstracted behind a service API, so we could plug in a different storage engine (Cassandra instead of JPA, for example) without needing to modify the other layers. The editor code currently has no knowledge of JPA, so I'd have to expose some of the business layer to implement either of my first two options.
Do you use any tools to make the copying easier, or do you code it by hand? Thanks, Chris On Wed, Mar 5, 2014 at 8:07 AM, <[email protected]> wrote: > Hi Chris, > > I would go for option 4. This is how I implement such cases. It has an > explicit distinction between states 'previewMode' and 'commited Mode'. > Looks like more coding, but actually is clear about distinction between > preview and saved. And that would help the programmer that picks this code > up a half year from now. > > My 2 cents. > > Best, > > Haiko > > Chris Snyder <[email protected]> schreef: > > > I'm dealing with an issue that I'm sure has been solved by many people on >> this list, but I'm struggling to ascertain the best way to solve it. >> >> I'm working on implementing in-place-edit functionality for some of our >> site content. The content is stored in a database and mapped via JPA. The >> edit form has the JPA entity as the backing model object. >> >> One of the features I'm implementing is the ability to preview what's been >> entered in the form without the updates being committed to the database >> (until the user explicitly clicks on the "Save" button). I can think of a >> few ways to accomplish this: >> >> 1. Rollback the transaction when not saving - This would require me to >> manage the transaction manually (right now, they're being managed >> automatically by Guice's PersistFilter). >> >> 2. Detach the object from the persistence context, merge it to save - This >> seems like the most elegant solution, but I can see how there could be >> issues (not intractable) with lazy loading. >> >> 3. Prevent the form from updating the model until save - This would break >> my preview panel, and seems to be contrary to how forms normally behave. >> >> 4. Copy the data into a non-managed DTO, copying it back to the JPA object >> on save - Would require a lot of clone/copy code. >> >> This seems like such a common problem to solve - I think my relative >> unfamiliarity with JPA is the main stumbling block here. How have others >> implemented it? Is there a best-practice pattern that my Googling didn't >> discover? >> >> Thanks in advance for the help. I hope that it isn't too off-topic since >> it >> is mainly JPA-related. >> >> Best, >> Chris >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
