Thanks, Igor - that's very helpful. Not sure how I missed that article while I was searching.
It would be a bit tricky to implement in my situation (as I described in another response, the JPA implementation of the data storage is abstracted behind a service API), but I could make it work - perhaps by adding detach and merge methods to the API; that would perhaps expose a little too much of the implementation, but I think that other (hypothetical) implementations could also need to expose similar functionality. Of course, I might be over-engineering this whole abstraction anyways. I have no intention of implementing a non-JPA version - perhaps I should embrace a hard dependency on JPA and simplify everything. JPA is itself an abstraction layer, after all... Thanks, Chris On Wed, Mar 5, 2014 at 11:44 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > 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 <chris.sny...@biologos.org> > 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: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Chris Snyder Web Developer, BioLogos 616.328.5218 x203 biologos.org
