you simple need to change where the entitymanager instance lives, and control it via cdi conversation api. no need to expose any more of the jpa stuff.
-igor On Wed, Mar 5, 2014 at 9:06 AM, Chris Snyder <[email protected]> wrote: > 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 <[email protected]>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 <[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] >> >> > > > -- > Chris Snyder > Web Developer, BioLogos > 616.328.5218 x203 > biologos.org --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
