have a look here: https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/
-igor On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder <[email protected]> wrote: > 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]
