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 <chris.sny...@biologos.org> 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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
