Hi Patrick, Thanks for the response.
does the Guice's PersistFilter really automatically find and re-attach > the backed object in the request while leaving the in-place-edit situation? Guice doesn't do anything with whether the objects are attached - I'm simply never detaching them (unless I implement option #2), so any changes made to the object are automatically persisted by the JPA engine. Guice's role here is with transactions - the PersistFilter starts a transaction at the beginning of the request, and commits it at the end. Thanks, Chris On Wed, Mar 5, 2014 at 8:29 AM, Patrick Davids <patrick.dav...@nubologic.com > wrote: > Hi Chris, > > I thought... as long as "nothing"/nobody finds and re-attach the backed > object, your changes are "naturally" temporary and only stored on page > cache. > > I would expect, it should already work out-of-the-box... But I did not > work with Guice's PersistFilter, yet. May I miss something... > > kind regards > Patrick > > Am 05.03.2014 12:47, schrieb Chris Snyder: > > 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 > > >
